Memoire Master Ok

République de Côte d’Ivoire
Union – Discipline - Travail
MEMOIRE DE FIN DE
CYCLE
En vue de l’obtention du diplôme Master Génie Informatique et Réseaux
Thème :
Présenté par : CREPPY William Ayité

MISE EN
Année académique : 2011 - 2012
PLACE
D’UNE
Maître de Stage :
Encadreur Pédagogique : APPLICATIO
M. Gilles FANOU
M. N’GUESSAN BLE Stéphane N POUR LE
Professeur àResponsable
PIGIER Coordination de projets
JFR-SYSTEMS
PAIEMENT
ELECTRONIQ
UE DES
FRAIS DE
SCOLARITE
Mémoire de fin de cycle Master Génie informatique et Réseaux
Paiement électronique de frais de scolarité
SOMMAIRE
SOMMAIRE..................................................................................................................................................II
DEDICACE...................................................................................................................................................IV
REMERCIEMENTS...................................................................................................................................V
AVANT-PROPOS......................................................................................................................................VI
RESUME....................................................................................................................................................VII
ABSTRACT (SUMMARY).....................................................................................................................VIII
INTRODUCTION...........................................................................................................................................1
PREMIERE PARTIE : CADRE DE REFERENCE..................................................................................................2
I- PRESENTATION DE L’ENTREPRISE.............................................................................................................3
I.1- Historique et présentation................................................................................................................3
I.2- Forme juridique.................................................................................................................................3
I.3- Domaines d’activités.........................................................................................................................4
I.4- Organisation de JFR-SYSTEMS...........................................................................................................4
II- PRESENTATION DU PROJET.....................................................................................................................7
I.1- Contexte (problématique).................................................................................................................7
I.2- Cahier des charges.............................................................................................................................8
I.3- Objectif..............................................................................................................................................9
III- CHOIX DE LA METHODE D'ANALYSE.......................................................................................................9
III.1-Définition des concepts..................................................................................................................10
III.2-Classification des méthodes d'analyse et de conception................................................................11
III.3-Choix d'une méthode d'analyse et de conception..........................................................................13
DEUXIEME PARTIE : ETUDE PREALABLE.....................................................................................................16
I- ETUDE DE L’EXISTANT.............................................................................................................................17
I.1-Description de l’existant...................................................................................................................17
I.2- Critique de l’existant........................................................................................................................17
CREPPY William Ayité

II
Etudiant en Master Génie Informatique et Réseaux
II - Proposition de solutions possibles.......................................................................................................18

II.1- Paiement en ligne...........................................................................................................................18
II.2- Paiement électronique...................................................................................................................19
TROISIEME PARTIE : ETUDE DETAILLEE......................................................................................................20
I- ETUDE CONCEPTUELLE...........................................................................................................................23
I-1 Modèle conceptuel des données (MCD)..........................................................................................23
I-2 Modèle conceptuel des traitements (MCT)......................................................................................27
II- ETUDE FONCTIONNELLE........................................................................................................................38
II.1- Modèle organisationnel des traitements (MOT)............................................................................38
II.2- Modèle logique de données (MLD)................................................................................................44
III- ETUDE ORGANIQUE..............................................................................................................................45
Modèle physique de données (MPD)....................................................................................................45
QUATRIEME PARTIE : DEPLOIEMENT ET INTEGRATION.............................................................................48
I- ETUDE TECHNIQUE ET PRESENTATION DES PLATEFORMES ATTAQUES.................................................49
I.1-Plateforme USSD..............................................................................................................................49
I.2-Plateforme Web...............................................................................................................................49
II- REALISATION.........................................................................................................................................55
II.1-Présentation des outils et langages utilisés.....................................................................................55
II.2- Présentation des fonctionnalités....................................................................................................58
III- DEPLOIEMENT DE LA SOLUTION...........................................................................................................69
III.1-Description de l'environnement de déploiement...........................................................................69
III.2- Les procédures de déploiement mise en place..............................................................................69
IV- SECURITE..............................................................................................................................................72
IV.1- Définition des profils utilisateurs...................................................................................................72
IV.2- Authentification des utilisateurs...................................................................................................73
CONCLUSION.............................................................................................................................................77
BIBLIOGRAPHIE ET/OU WEBOGRAPHIE.....................................................................................................IX
ANNEXE.......................................................................................................................................................X
TABLE DES MATIERES..............................................................................................................................XVII

III
DEDICACE
A mon Père CREPPY John Daniel, ma mère CREPPY née KOUAME Ahou
Eugénie, et toutes les personnes qui nous ont apporté leur soutien.

IV
REMERCIEMENTS
Nous tenons à manifester notre gratitude à des personnes particulières qui ont permis
la réalisation de ce travail et grâce à qui nous sommes parvenus à la fin de notre formation.
Sans être exhaustif, nous aimerions citer :
Toute l’équipe de JFR-SYSTEMS, en particulier le Directeur Général, Monsieur Armel

BEDIE pour l'opportunité qui nous a été donnée de faire notre stage au sein de son
entreprise;
Mme TRA ZIE Abina Caroline, Chef du département informatique à PIGIER Côte d'Ivoire,
pour sa disponibilité ;
M. N’GUESSAN BLE Stéphane, mon professeur encadreur, pour sa disponibilité, la
pertinence de ses remarques et tous les efforts consentis ;
Tout le corps professoral et administratif de PIGIER Côte d'Ivoire, pour le savoir transmis
au prix de sacrifices personnels ;
Ceux qui nous ont soutenus et continuent de nous soutenir par leurs prières et leurs
pensées.

V
AVANT-PROPOS
De nombreux établissements de l’enseignement professionnel ont vu le jour ces
dernières décennies dans le fichier du ministère de tutelle. Ces nouveaux établissements n’ont
pas la maestria des établissements traditionnellement reconnus dans le domaine de la
formation tel que PIGIER Côte d’Ivoire.
Cette école de par son travail et son sérieux a réussi à mettre d’accord tout le monde sur
la qualité de ses formations. La reconnaissance Africaine de ses diplômes par leurs certifications
CAMES n’est donc pas fortuite. Le statut de la formation adoptée par PIGIER Côte d’Ivoire est
celui de la formation initiale avec le système LMD (Licence Master Doctorat). A PIGIER Côte
d’Ivoire, la formation est donnée dans diverses filières parmi lesquelles nous pouvons citer :
 La filière Informatique ;
 La filière Comptable ;
 La filière Communication ;
 La filière Gestion Commerciale ;
 La filière Bureautique.
A la fin du cycle de Master, l’auditeur est appelé à mener un projet de fin d’études,
comme celui-ci sous la direction de ses professeurs et éventuellement des personnes externes.
Ce projet lui permettrait de mettre en application les différentes connaissances théoriques et
pratiques acquises lors de son cycle.

VI
RESUME
De nos jours, le traitement de données a atteint un développement technologique
extraordinaire dans divers domaines (réseaux, bases de données, Web, etc.). Cette évolution
est nécessaire pour traiter les problèmes rencontrés dans la vie courante.
Le dynamisme est l'une des caractéristiques les plus essentielles de traitement de données. Il
est celui qui nous a poussés à créer un service Web dynamique, accessible pour les
établissements via Internet et pour les abonnées téléphoniques via USSD.
Chaque création nécessite différentes étapes prévues par la méthode MERISE, la

réalisation quant à elle nécessite des outils de développement bien adaptés au contexte de
l'application. Pour les bases de données, l'utilisation d'un SGBD tel que SQL Server, MySQL,
Oracle, PostgreSQL, etc est essentiel.
Notre travail consiste à concevoir un service à trois niveaux (application Web, service
USSD, API) en utilisant une base de données centralisée, pour le paiement des frais de scolarité
des élèves des établissements de Côte-d'Ivoire. L'application a été développée en utilisant
divers logiciels tels que Visual Studio, SQL SERVER, Adobe Photoshop, Eclipse. Le langage de
programmation utilisé est le C#, mais aussi le Java.

VII
ABSTRACT (SUMMARY)
Today, data processing reached an extraordinary technological development in various
fields (data-processing networks, databases, the Web, etc). This evolution is necessary to cure
the problems encountered in the current life.
The dynamism is one of the most essential characteristics of data processing. It is that which
pushed us to create dynamic Web Service, for Schools via Internet and for phone users via
USSD.
Each creation requires different steps specified by MERISE method, the realization as for it
requires development tools adapted well to the context of the application. For the databases,
the use of a DBMS such as SQL SERVER, MySQL, ORACLE, PostgreSQL, etc is essential.
Our work consists in conceiving a Web service to three levels (Web application, USSD
Service, API) by using a database centralized, for the academic school fees payment of the
students in Ivory Coast. The application was developed by using various data-processing
software such as Visual Studio, SQL SERVER, Adobe Photoshop, and Eclipse. The programming
language used is the C#, but also JAVA.

VIII
INTRODUCTION
Les établissements privés de même que les établissements publics dépendent en partie
de leurs outils de gestion de système d’information. Les nouvelles technologies de l’information
et de la communication et l’avènement de l’internet ouvrent un large champ de possibilités
dans la gestion des systèmes d’information, mais exigent pour être mises en œuvre, avec
succès, des moyens matériels, logiciels et une main d’œuvre qualifiée.
Actuellement, les établissements en général ne disposent pas encore d’outil pour la

collecte en banque des frais de scolarité, ce qui aura pour but de gérer et suivre efficacement
les paiements des élèves.
Du point de vue du développement du service, l’exercice le plus prenant a été celui de
l’élaboration du cahier des charges. Il ne s’agit pas d’une sollicitation client. Le service « Frais
Scolaires » est une initiative pour combler ces manques, d’où la naissance de ce projet « Mise
en place d’une application pour le paiement électronique des frais de scolarité ».
Il a donc fallu se mettre dans la peau des utilisateurs, mieux, il a fallu penser comme les parents
d’élèves et les fondateurs d’établissements, premiers concernés par ce service.
Ainsi, la réalisation de cette étude va-t-elle nous amener à répondre à plusieurs

préoccupations d’ordre technique, humain et organisationnel.
Quelle application pourrait-elle répondre à une gestion efficiente et efficace du suivi de ce flux ?
La réponse à cette problématique nous amènera à proposer un travail qui s'articulera autour de
quatre grands axes majeurs que sont:
1- L’approche méthodologique ;
2- L’étude technique ;
3- La réalisation ;
4- Le déploiement.
1
PREMIERE PARTIE : CADRE DE REFERENCE
PREMIERE PARTIE :
CADRE DE
REFERENCE
2
I- PRESENTATION DE L’ENTREPRISE
I.1- Historique et présentation

A l’origine, en 1999, le concepteur des solutions logicielles de JFR-SYSTEMS a conçu et
développé ses progiciels pour des particuliers en tant que consultant indépendant. Au fil des
années, il y a apporté de multiples améliorations avant de créer en 2008 JFR-SYSTEMS.
Au cours de ces années de développement, les différentes plates-formes logicielles ont

acquis une performance réelle sans pour autant perdre la facilité d’utilisation et la flexibilité qui
ont fait leur succès. Mieux, grâce aux nombreuses extensions techniques mises en œuvre, ces
progiciels sont devenus aujourd’hui incontournables dans leurs différents secteurs cibles.
JFR-SYSTEMS est une société de services en ingénierie informatique basé en Côte

d’Ivoire, au Bénin et dans quelques pays sur le continent africain.
Elle propose une solution complète d’intégration et de maintenance de solutions informatiques

appropriées aux entreprises et aux organisations de grandes tailles.
Elle met à la disposition de l'ensemble des acteurs du système éducatif, les moyens techniques
nécessaires afin de résorber les problèmes essentiels de contrôle de leur activité.
Les objectifs principaux sont :
 Un inventaire précis et dynamique des centres et établissements académiques publics et
privés sur un territoire ;
 La maîtrise du répertoire des inscrits par filière, séries, communes, villes, sous régions,
régions, territoire ;
 Un suivi en temps réel de l'évolution de l'activité pédagogique avec des analyses relatives
de performances scolaires ;
 Une réelle fiabilisation des résultats scolaires, examens partiels et examens annuels ;
 Une plus grande capacité d'anticipation des carences et insuffisances de l'appareil éducatif.
I.2- Forme juridique

La société JFR-SYSTEMS est une SARL (société à responsabilité limitée) au capital de
10.000.000 FCFA dirigée par M. BEDIE Kosso Armel, Directeur Général.
3
I.3- Domaines d’activités
JFR-SYSTEMS, pluridisciplinaire, garantit des services de qualités et intervient dans les
domaines suivants :
 Ingénierie informatique ;
 L’installation et la maintenance de réseaux et de télécommunication ;
 La commercialisation de matériel périphérique et consommable informatique ;
 La mise en place de réseaux de courant ondulé ;
 Le câblage de réseaux téléphoniques.
I.4- Organisation de JFR-SYSTEMS
I.4.1- Direction générale

Elle est assurée par M. BEDIE Kosso Armel. Il supervise l’ensemble du personnel et
assure la responsabilité de l’ensemble des missions réalisées par la structure.
I.4.2- Secrétariat
Assuré par Mlle DJEDRO RAMA, elle s’occupe de la saisie des différents courriers (notes
de services, lettres commerciales…) et des rapports de réunion.
I.4.3- Service comptabilité

Il est assuré par M. SILUE TIMAN et M. FABRICE ATTA, qui s’occupe de :
 Le traitement des factures fournisseurs (réception, imputations, saisies, archivage et

règlement) ;
 Elaboration et règlement des déclarations fiscales et sociales ;
 Elaboration des dossiers financiers internes et externes ;
 Le classement des pièces comptable ;
 Les encaissements et des décaissements.
I.4.4- Service commercial
4
Assuré par M. Gilles FANOU, Il gère la synthèse des actions commerciales, recherche de
nouveaux clients et de nouveaux partenaires. Il propose une politique agressive
d’intéressement des clients et organise des séminaires, des démonstrations et des conférences
de découverte des produits.
Il s’occupe de l’organisation de la Communication (émissions radio, émissions télévisées,
journaux, presse) et de l’organisation de la participation aux rendez-vous du monde scolaire :
syndicats, fédérations, DREN, SAPEP, ONG,...
I.4.5- Service technique
Assuré par M. YEO NAMOGOH et un ensemble de techniciens en informatique et en

génie logiciel qui ont pour mission :
 La création et l’hébergement de site web ;

 La mise en place et la maintenance d’un systeme d’interconnexion entre un nombre
indéfini d’ordinateurs ;
 La mise en place d’un réseau informatique.
I.4.6- Formateurs-intégrateurs
Ils ont pour rôle de recueillir les informations sur le terrain, de former les différentes
personnes et d’acheminer les données chez les développeurs.
I.4.7- Service Génie logiciel et logistique
Il assure l’effectivité du développement des nouvelles fonctionnalités applicatives de la

plate-forme de l’ERPLIGES en tenant compte des cahiers des charges du service technique.
Il gère le développement et le classement de tous les états statistiques particuliers et

met à la disposition des autres services la logistique nécessaire pour la bonne exécution de
leurs feuilles de route.
Il a aussi pour rôle d’assurer la rédaction et la diffusion des supports électroniques de

formation et de contrôler la réalisation des sauvegardes régulières des plates-formes de l’ERP-
LIGES.
5
ORGANIGRAMME DE JFR-SYSTEMS
Direction Générale
Service Service technique Service administratif et Service génie logiciel et

commercial financier logistique
6
II- PRESENTATION DU PROJET
I.1- Contexte (problématique)

A la rentrée scolaire, et au cours de l’année académique, les parents d’élèves s’acquittent
des frais scolaires pour la plupart du temps en faisant un versement directement auprès de la
caisse au sein de l’établissement scolaire.
Les frais scolaires sont repartis en trois 3 types : Frais d’inscription (droit d’inscription + frais
annexes), Frais d’écolage, Droit d’examen pour les classes d’examen.
Exemple d'échéancier d’un établissement de la place.
Echéance 01 Echéance 02 Echéance 03
Date Montant Date Montant Date Montant
Frais de scolarité 15 000 15 000 20 000
Frais d'inscription
Cantine 5 000 5 000 5 000
Transport 2 500
Infirmerie
Assurance
Activités culturelles
Vaccinations
Visites médicales
Paiement électronique 1 000 1 000 1 000
Le projet « Frais Scolaires » vise à permettre aux parents de payer les frais de scolarité en
évitant le déplacement, les longues files d’attente, les cas de vols, etc. Et aux établissements
scolaires de sécuriser leurs fonds, tout en gardant une réelle traçabilité des transactions de
paiement.
7
I.2- Cahier des charges
Le système à mettre en place pour la gestion des paiements depuis le parent d’élève
jusqu’au niveau établissement sera scindé en trois modules que sont:
 Module (plateforme) dédiée à la mise en exploitation et au suivi du bon fonctionnement

des opérations de paiements électroniques ;
 Module pour le service USSD (Unstructured Supplementary Services Data);
 Module API (Application Programming Interface) pour l’échange d’informations entre la
plateforme établissement et le service USSD ;
 Module Administrateur pour le virement des montants recueillis pour chaque
établissement.
I.2.1- Module dédiée à la mise en exploitation et au suivi du bon

fonctionnement des opérations de paiements électroniques
Ce module devra permettre aux établissements d’accéder à un espace où ils pourront :
 S’enregistrer à la plateforme ;
 Importer à partir d’un fichier Excel les élèves qu’ils ont à leur charge ainsi que leur
échéancier ;
 Consulter dans un tableau de bord les paiements effectués des élèves, le montant viré
sur leur compte, l’état de la caisse etc…
I.2.2- Module pour le service USSD
Ce module permettra d’échanger avec les opérateurs téléphoniques. Il a pour but de

transmettre à l’opérateur les messages que ceux-ci devront afficher aux différents clients
désirant utiliser le service après avoir saisi une chaine de caractères sur leur téléphone
(Exemple : #000#).
I.2.3- Module API
L’API, pour Application Programming Interface, est le module qui permettra au service
USSD d’échanger avec la plateforme renseignée par les différents établissements utilisant
« Frais Scolaires ».
8
I.2.4- Module Virement
Ce module permettra à la plateforme de générer un fichier Excel sur une fréquence bien
défini (Exemple : deux semaines) qui fera le point des paiements par établissement.
Ce fichier sera mis à disposition de la banque et après confirmation des différents virements, la
plateforme Web sera mise à jour.
I.3- Objectif
Le service « Frais Scolaires », disponible via USSD sur les réseaux ORANGE, MTN et MOOV,
vise à permettre aux abonnés de payer les frais scolaires à travers leurs comptes MOBILE
MONEY.
III- CHOIX DE LA METHODE D'ANALYSE

Un projet informatique, quelle que soit sa taille et la portée de ses objectifs, nécessite la
mise en place d'un planning organisationnel tout au long de son cycle de vie. C'est ainsi qu'est
apparue la notion de méthode.
Une méthode, dans le contexte informatique, peut être définie comme une démarche
fournissant une méthodologie et des notations standards qui aident à concevoir des logiciels de
qualité.
Modéliser un système avant sa réalisation permet de mieux comprendre le

fonctionnement du système. C'est également un bon moyen de maîtriser sa complexité et
d'assurer sa cohérence. Un modèle est un langage commun, précis, qui est connu par tous les
membres de l'équipe et il est donc, à ce titre, un vecteur privilégié pour communiquer. Cette
communication est essentielle pour aboutir à une compréhension commune aux différentes
parties prenantes (notamment entre la maîtrise d'ouvrage et la maîtrise d'œuvre informatique)
et précise d'un problème donné.
Dans le domaine de l'ingénierie du logiciel, le modèle permet de mieux répartir les

tâches et d'automatiser certaines d'entre elles. C'est également un facteur de réduction des
coûts et des délais. Par exemple, les plateformes de modélisation savent maintenant exploiter
les modèles pour faire de la génération de code (au moins au niveau du squelette) voire des
9
allers-retours entre le code et le modèle sans perte d'information. Le modèle est enfin
indispensable pour assurer un bon niveau de qualité et une maintenance efficace car, une fois
mise en production, l'application va devoir être maintenue, probablement par une autre équipe
qui n’est pas nécessairement de la même société que celle l’ayant créée. Le choix du modèle a
donc une influence capitale sur les solutions obtenues. Les systèmes non triviaux sont mieux
modélisés par un ensemble de modèles indépendants. Selon les modèles employés, la
démarche de modélisation n'est pas la même.
III.1-Définition des concepts
Une méthode fait intervenir essentiellement les concepts d'analyse et de conception.
III.1.1-L'analyse
Correspondant à la phase qui répond à la question « que fait le système », l'analyse est
l'une des étapes les plus importantes et les plus difficiles de la modélisation. Elle permet de
modéliser le domaine d'application, d'analyser l'existant et les contraintes de réalisation. Elle
s'effectue par une abstraction et une séparation des problèmes. Elle peut être découpée en
trois phases que sont :
III.1.1.1-La définition des besoins
Il s'agit d'identifier les acteurs et les cas d'utilisation, de structurer le modèle, et

d'identifier les autres exigences.
III.1.1.2-La capture des besoins
Elle consiste à collecter des informations (interviews, lecture de documentation) et à la

compréhension du domaine et du problème posé.
A ce niveau, il s'agit de restituer les besoins dans un langage compréhensible par le

client et de procéder à l'identification, à la structuration et à la définition d'un dictionnaire.
III.1.1.3-La spécification des besoins
Dans cette phase, il sera question d'aller à un niveau de spécification plus détaillé voire
même plus formel des besoins. Elle sera d'une grande utilité pour le client mais aussi pour le
développeur.
10
A la fin de cette phase d'analyse, un modèle conceptuel sera disponible, lequel modèle
sera un outil fondamental lors de la phase de conception.
III.1.2-La conception
Phase menée à la suite de l'analyse des besoins, la conception met en œuvre tout un
ensemble d'activités, qui à partir d'une demande d'informatisation d'un processus permettent
la conception, l'écriture et la mise au point d'un produit informatique (et donc de programmes
informatiques) jusqu'à sa livraison au demandeur. Elle a comme objectifs de répondre à la
question « comment faire le système ?» et de décomposer de façon modulaire le système à
mettre en place. La conception définit l'architecture du logiciel. Elle définit par la même
occasion chaque constituant du logiciel (Informations traitées, traitements effectués, résultats
fournis, contraintes à respecter). A la suite, un modèle logique utilisable à la phase
d'implémentation est produit.
III.1.3-L'implémentation
Cette phase consiste à la mise en œuvre des programmes dans un langage de

programmation conformément aux spécifications définies dans les phases précédentes. Elle
renferme en son sein les phases de test et de mise au point (débogage). A la sortie, il sera
produit un modèle physique (collection de modules implémentés mais non testés,
documentation de programmation expliquant le code).
III.2-Classification des méthodes d'analyse et de conception
Malgré la diversité des méthodes d'analyse et de conception, il est possible de les

classer en trois catégories :
III.2.1-Les méthodes cartésiennes ou fonctionnelles
Avec cette méthode, le système étudié est abordé par les fonctions qu'il doit assurer
plutôt que par les données qu'il doit gérer. Le processus de conception est vu comme un
développement linéaire. Il y a décomposition systématique du domaine étudié en sous
domaines, eux-mêmes décomposés en sous-domaines jusqu'à un niveau considéré
élémentaire. SADT (Structured-Analysis-Design-Technique) en est un exemple.
11
III.2.2-Les méthodes systémiques
Les méthodes systémiques sont des méthodes s'appuyant sur une approche
systémique. Elles définissent différents niveaux de préoccupation ou d'abstraction et proposent
de nombreux modèles complémentaires. Les méthodes systémiques sont souvent spécialisées
pour la conception d'un certain type de systèmes. Comme exemple de méthode systémique
nous pouvons citer MERISE, AXIAL ...
III.2.3-Les méthodes objet
Ce sont des méthodes consistant à créer une représentation informatique des éléments
du monde réel auxquels on s'intéresse, sans se préoccuper de l'implémentation, ce qui signifie
indépendamment d'un langage de programmation. Il s'agit donc de déterminer les objets
présents et d'isoler leurs données et les fonctions qui les utilisent. Pour cela, des méthodes ont
été mises au point. Entre 1970 et 1990, de nombreux analystes ont mis au point des approches
orientées objets, si bien qu'en 1994 il existait plus de 50 méthodes objet. Toutefois seules 3
méthodes ont véritablement émergé :
· La méthode OMT de Rumbaugh ;
· La méthode BOOCH'93 de Booch ;
· La méthode OOSE de Jacobson ;
III.2.4-Les méthodes agiles
Les méthodes de développement dites « méthodes agiles » (en anglais Agile Modeling)
visent à réduire le cycle de vie du logiciel (donc accélérer son développement) en développant
une version minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur
une écoute client et des tests tout au long du cycle de développement.
L'origine des méthodes agiles est liée à l'instabilité de l'environnement technologique et au

fait que le client est souvent dans l'incapacité de définir ses besoins de manière exhaustive dès
le début du projet. Le terme « agile » fait ainsi référence à la capacité d'adaptation aux
changements de contexte et aux modifications de spécifications intervenant pendant le
processus de développement. En 2001, 17 personnes mirent ainsi au point le manifeste agile
dont la traduction est la suivante :
- individus et interactions plutôt que processus et outils ;
12
- développement logiciel plutôt que documentation exhaustive ;
- collaboration avec le client plutôt que négociation contractuelle ;
- ouverture au changement plutôt que suivi d'un plan rigide.
Grâce aux méthodes agiles, le client est pilote à part entière de son projet et obtient
très vite une première mise en production de son logiciel. Ainsi, il est possible d'associer les
utilisateurs dès le début du projet. Comme méthode agile, nous pouvons citer eXtreme
Programming (XP).
III.3-Choix d'une méthode d'analyse et de conception
Dans cette partie, nous ferons une étude approfondie de deux méthodes d'analyse et de
conception. Enfin nous effectuerons un choix parmi ces dites méthodes.
III.3.1-Merise
MERISE est avant tout une méthode de conception de système d’informations et une
démarche méthodologique de développement. MERISE constitue simultanément, une méthode
de conception et une démarche méthodologique de développement de système
d’informations. La méthode MERISE, très analytique, distingue nettement les données des
traitements, même si les interactions entre les deux sont profondes et s’enrichissent
mutuellement (validation des données par les traitements et réciproquement). La séparation
des données et des traitements assure une longévité au modèle. En effet, l'agencement des
données n'a pas à être souvent remanié, tandis que les traitements le sont plus fréquemment.
MERISE propose une démarche de conception d'un SI qui consiste à traiter un projet
informatique en utilisant les différentes étapes suivantes :
 Schéma directeur ;
 Etude préalable ;
 Analyse détaillée ;
 Analyse technique ;
 Réalisation ;
 Maintenance.
13
III.3.2-Processus unifié
Le processus unifié est une méthode générique de développement de logiciels. Il est

générique puisqu’il est nécessaire de l’adapter au contexte du projet, de l’équipe, du domaine
et/ou de l’organisation. Cette méthode regroupe les activités à mener pour transformer les
besoins d’un utilisateur en système logiciel. De plus, le processus unifié :
 est à base de composants ;
 utilise le langage UML ;
 est piloté par les cas d’utilisation ;
 est centré sur l’architecture ;
 est itératif et incrémental.
En outre, le langage de modélisation UML qu’il utilise n’est qu’un langage graphique de
modélisation des données et des traitements. C’est une formalisation très aboutie et non-
propriétaire de la modélisation objet. Depuis novembre 2007, sa version 2.1.2 est diffusée par
l’Object Management Group (OMG). Ce langage de modélisation est l’accomplissement de la
fusion des précédents langages de modélisation objet Booch, OMT, OOSE. Principalement issu
des travaux de GradyBooch, James Rumbaugh et Ivar Jacobson, UML qui est à présent un
standard défini par l’OMG, n’est pas une méthode, mais seulement un langage graphique qui
permet de représenter, de communiquer les divers aspects d’un système d’informations.
Compte tenu du fait, qu’il soit impossible de donner une représentation graphique
complète d’un logiciel, ou de tout autre système complexe, UML propose des vues partielles
dont la juxtaposition donnera une idée utilisable en pratique sans risque d’erreur grave. Ainsi
UML 2.0 comporte treize diagrammes représentant autant de vues distinctes pour représenter
les concepts particuliers du système d’exploitation.
14
III.3.3- Choix de la méthode d’analyse et de conception
Le tableau suivant établit une comparaison par une opposition point par point des
caractéristiques de ces deux méthodes:
CRITERES MERISE/2 PROCESSUS UNIFIE D’UML
Données et Séparation des données et des Regroupement des données et méthodes

traitement traitements. au sein des classes. Application du
s principe de l’encapsulation.
Plusieurs niveaux : conceptuel, Niveau unique mais plusieurs types de

logique, organisationnel, physique modèles en fonction de l’aspect à décrire.
avec plusieurs types de modèles : Affinement des modèles lors des
Niveaux données, traitements, différentes étapes de l’analyse et de la
communication. Existence de règles conception. Continuité entre les
de passage entre les différents différentes phases d'élaboration de
niveaux. l'application (traçabilité).
Concentré principalement sur la Prise en compte de tous les stades de la

conception, sans prise en compte de conduite d'un projet.
Gestion de
la phase de programmation (modèle Cohérence de la phase d’analyse jusqu’au
projet
de déploiement et de composant code du programme.
absent)
Tableau 1:Tableau comparatif MERISE- Processus Unifié d'UML
L’analyse du tableau ci-dessus permet de relever plusieurs points. Mais l’élément

majeur est que UML est basé sur l’approche objet et est très souvent utilisé dans l’informatique
technique (temps réel).
La méthode MERISE présente l'intérêt d'avoir des modèles logiques moins détaillés facilement
compréhensibles. Elle est donc la méthode d’analyse que nous avons retenue car elle nous
permettra d’interagir facilement avec la base de données (stockage et consultation) des traces
de toutes les actions effectuées par les utilisateurs.
15
DEUXIEME PARTIE : ETUDE PREALABLE
DEUXIEME PARTIE :
ETUDE
PREALABLE
16
I- ETUDE DE L’EXISTANT
Afin de mener à bien notre étude et surtout de prendre en compte tous les aspects
techniques et fonctionnels qui entourent le projet, il convient d’étudier les éléments existants
dans le système actuel et de faire par la suite quelques critiques.
I.1-Description de l’existant
A la rentrée scolaire et au cours de l’année académique, les parents d’élèves
s’acquittent des frais scolaires pour la plupart du temps en faisant un versement directement
auprès de la caisse au sein de l’établissement scolaire.
I.2- Critique de l’existant

Cette situation a plusieurs conséquences sur l’activité scolaire, aussi bien pour les
parents d’élèves que pour les établissements scolaires. Nous pouvons citer entre autres :
I.2.1- Pour les établissements scolaires
1. Important risque de braquages au sein de l’établissement scolaire. Souvent ces

phénomènes sont meurtriers ;
2. Les cas de vols et de détournement sont fréquents. Souvent organisés en complicité avec
les caissiers eux-mêmes ;
3. Il y a souvent des braquages lors des opérations de transferts de fonds;
4. Les opérations de transferts de fonds sont par ailleurs onéreuses pour les fondateurs
d’écoles ;
5. Il est impossible pour les fondateurs de contrôler les versements des parents d’élèves, à
cause du nombre d’élèves et de l’affluence à la rentrée ;
6. Ils (fondateurs) ne peuvent non plus savoir avec exactitude qui a payé, et qui n’a pas payé.
Toute la trésorerie repose sur le bon vouloir de l’intendant et des caissiers. Et ils n’y
peuvent rien ;
7. La conséquence de ce manque de visibilité est la multiplication des cas de réclamations de
paiements non parvenus au cours de l’année académique ;
8. Actuellement, il est impossible pour un fondateur qui a plusieurs établissements scolaires
de contrôler avec efficacité les paiements des frais de scolarités. Les pertes sont vraiment
17
importantes. Et cet état des choses fait partie des facteurs bloquant les projets d’expansion
de leurs activités ;
9. Les cas de litiges liés aux frais de scolaires non parvenus sont supportés à contrecœur par
les établissements scolaires, et donc les fondateurs, car eux-mêmes n’ont aucun moyen de
dire justifier ces situations ;
Tous les facteurs ci-dessus ne contribuent pas à la bonne image des établissements scolaires.
I.2.1-Pour les parents
Lorsque les parents d’élèves sont contraints de faire parvenir les frais de scolarité
physiquement jusqu’à la caisse des établissements scolaires fréquentés par leurs enfants,
plusieurs situations critiques et difficultés se posent également :
1. Les difficultés voire impossibilité de déplacement physique vers les établissements scolaires
liées à plusieurs facteurs (maladie, distance, occupations professionnelles, etc.) font que
l’argent est confié à une tierce personne et parfois l’élève lui-même ; Les cas de
détournement d’argent qui découlent de ces situations sont très nombreux à chaque
rentrée scolaire ;
2. Les parents n’ont pas souvent accès à l’information de l’effectivité du paiement des frais de
scolarité, lorsque ce n’est pas eux-mêmes qui s’en acquittent. Les impayés ne sont décelés
que lorsque les élèves sont mis à la porte pour non-paiement. S’en suivent des situations de
contentieux très complexes, parfois avec des parents d’élèves jugés respectueux et fidèles
aux établissements scolaires ;
3. Les parents d’élèves font parfois une longue file d’attente afin de payer les frais d’écolage.
Au cours de toutes ces péripéties, les cas de petits vols font légion : dans le bus, dans
l’école, dans le taxi, etc. ;
4. Il n’est pas possible pour un parent qui est mobile, du fait de son activité professionnelle, ou
toute autre raison, de vérifier la situation financière de ses enfants vis-à-vis de leurs
établissements scolaires.
II - PROPOSITION DE SOLUTIONS POSSIBLES
II.1- Paiement en ligne
II.1.1- Description de la solution
18
Payer en ligne signifie payer via Internet. Parfois appelé « e-paiement » ou « monnaie
électronique », le paiement sur Internet s'est développé parallèlement à la croissance du
commerce électronique. Le paiement en ligne se fait dans la partie sécurisée du site d'un
commerçant ou sur le site Internet d'une banque.
Pour pouvoir payer en ligne, il suffit d'indiquer le numéro de carte de banque et sa date
d'expiration. Cela est possible grâce à la signature et au certificat électroniques. Les
transactions, quant à elles, se font très souvent entre une banque et un service de paiement
spécialisé (PSP), via des moyens de paiement.
II.1.2- Inconvénients
Avant d'effectuer un achat en ligne, il faut se poser plusieurs questions :
 Est-ce que le site dispose d'un label sécurité ?

 Est-ce que mes transactions par carte bancaire sont assurées ?
Le principal danger du paiement en ligne est le phishing, qui signifie « hameçonnage ». C'est
une technique frauduleuse qui cherche à usurper les identités bancaires.
Autre véritable souci qui pourrait se poser, le parent devra nécessairement avoir un compte
bancaire et une connexion internet. Ceci causerait un frein dans l’avancement du projet surtout
que dans certaines régions de notre pays, l’accès à internet se fait péniblement.
II.2- Paiement mobile
II.2.1- Description de la solution
Les paiements mobiles désignent toutes les transactions effectuées depuis un téléphone

mobile et débitées soit sur une carte bancaire, soit sur la facture opérateur ou soit sur un Porte-
monnaie électronique, qui peut être alimenté avec un dépôt de cash auprès d'un agent ou d'un
commerçant.
Le transfert d’argent de mobile à mobile est particulièrement développé dans les pays
émergents où une grande partie de la population n'a pas de compte bancaire, notamment en
Afrique Sub-saharienne.
Au-delà des acteurs historiques du transfert d'argent domestique et international (Express
Union, Western Union, MoneyGram), de nombreux opérateurs téléphoniques proposent des
comptes de monnaie électronique associés au numéro de mobile, permettant d'accéder à une
19
gamme de services, notamment transfert d'argent, paiement de factures et achat de crédit
téléphonique. (Orange money à Madagascar et en Côte d'Ivoire, le compte nomade "CashWay"
au Cameroun, Lemon Way au Mali, Tigo Cash ou Airtel Mobile au Tchad, M-Pesa au Kenya,
Tanzanie et Afrique du Sud).
II.2.2- Inconvénients
Comme inconvénients, nous pouvons citer entre autres le fait que le paiement dépend
du téléphone, le manque de batterie paralyse le paiement ; mais aussi les surcharges ou pannes
chez l’opérateur téléphonique, rendant presqu’impossible aucune transaction sur le réseau.
II.3- Choix d’une solution
II.3.1- Avantages
Ces deux solutions répondront aux différents besoins de faciliter les paiements dans le
profit non seulement des parents mais aussi des établissements. Mais la solution électronique
(paiement mobile) étendra davantage le nombre d’utilisateurs du service. Étant sûr qu’à défaut
d’une connexion internet et d’un compte bancaire, les parents devront seulement se prévaloir
d’un compte mobile money et d’un accès au réseau téléphonique pour bénéficier des
avantages du service.
La conception du service "Frais scolaires" permettra :
 Aux établissements scolaires
1. Réduction voire annulation du risque de braquages ;

2. Réduction voire annulation des vols des caissiers ;
3. Réduction de la lenteur de la disponibilité de l'argent ;
4. Pas de frais de transferts de fonds ;
5. Pas de risque lors des transferts de fonds ;
6. Plus visibilité de la trésorerie ;
7. Réduction voire annulation des réclamations de paiements non parvenus ;
8. Réduction voire annulation des pertes importantes de caisse ;
9. Facilité de contrôle des sites distants appartenant au même fondateur/propriétaire
d’écoles ;
10. Meilleure image vis-à-vis des parents d’élèves ;
20
11. Communication d’une notion de ‘bonne gouvernance’ aux futurs adhérents à
l’établissement.
 Aux parents d’élèves
1. Plus de sécurité du paiement des frais scolaires ;

2. Plus de visibilité : lecture continue de la situation financière de chaque élève ;
3. Mobilité lors du paiement des frais scolaires (plus besoin de se déplacer jusqu’à l’école) ;
4. Consultation des échéances détaillées à partir du mobile ;
5. Souscription rapide à tous les autres événements (culturels, sportifs, etc.) de
l’établissement.
II.3.2- Estimation des coûts de mise en œuvre

- Au niveau logiciel
Au niveau logiciel Prix unitaire (f CFA) Quantité Total (f CFA)

SQL Server 2008 7 131 472,670 FCFA 1 7 131 472,670 FCFA
Visual Studio 2010 484 652,223 FCFA 1 484 652,223 FCFA
DevExpress 1 218 985,72 FCFA 1 1 218 985,72 FCFA
Eclipse 0 1 0
Total 8 835 110,61 FCFA
- Au niveau matériel
Au niveau Matériel Prix unitaire (f CFA) Quantité Total (f CFA)

Serveurs dédiés 5 000 000 FCFA 2 10 000 000 FCFA
- Au niveau du développement
Le coût de réalisation est estimé à 1 200 000 FCFA.
Le cout total de mise en œuvre est de : 20 035 110,61 FCFA
21
TROISIEME PARTIE : ETUDE DETAILLEE
TROISIEME PARTIE :
ETUDE
DETAILLEE
22
I- ETUDE CONCEPTUELLE
I-1 Modèle conceptuel des données (MCD)
I.1.1- Définition
Le modèle conceptuel des données est la représentation schématique de l’aspect

statique du système d’information ; il représente les données et leurs dépendances
fonctionnelles.
I.1.2- Concepts de base
Le MCD manipule les concepts tels que :

 Entité : c’est tout objet matériel ou non, manipulé dans le domaine considéré et ayant
un intérêt propre pour l’entreprise ;
 Relation (Association) : c’est le lien sémantique existant entre deux ou plusieurs
entités ;
 Propriété : c’est un élément caractéristique de l’objet ;
 Identifiant : c’est une propriété obligatoire et unique permettant de distinguer les
objets entre eux ;
 Cardinalité (a, b) : c’est un couple indiquant le nombre minimum (a) et maximum (b)
qu’une occurrence de l’entité participe à une relation.
I.1.3- Représentation schématique
ENTITE A ENTITE B
(a, b) (a, b)
Identifiant A ASSOCIATION Identifiant B
Propriété A 1 OU Propriété B 1
Propriété A 2 RELATION Propriété B 2
. .
. .
Propriété A n Propriété B n
CARDINALITES
23
 Dictionnaire des Données (DD)
Nature
Long Observa
Code Description Type E/CO/C SIG/SIT/M
ueur tions
A VT
ID_CLASSE Identifiant d'une classe N 8 E SIG ID
LIBELLE_CLASSE Libellé d'une classe AN 50 E SIG
ID_ECHEANCE Identifiant d'une échéance N 8 E SIG ID
DATE_ECHEANCE Date d'une échéance AN 15 E SIG
MONTANT Montant d'une échéance N 8 E SIG
MONTANT_REGLE Montant réglé d'une échéance N 8 E SIG

NUM_ECHEANCE Numéro d'une échéance N 8 E SIG
Solde avant mise à jour du
SOLDEAVTPAIEMENT montant réglé N 8 E SIG
MATRICULE Matricule scolaire d'un inscrit AN 20 E SIG ID
EXERCICE Année scolaire d'un inscrit N 8 E SIG
NOM_ELEVE Nom d'un inscrit AN 100 E SIG
PRENOMS_ELEVE Prénoms d'un inscrit AN 100 E SIG
IDPAIEMENT Identifiant du paiement N 8 E SIG ID
Date et heure d'envoi de la
DATE_HEURE_ENVOI requete a l'operateur AN 15 E SIG
Date et heure de reponse de
DATE_HEURE_REPONS la requete de la part de
E_PAIEMENT l'operateur AN 15 E SIG
Etat de transfert d'un
ETAT paiement N 8 E SIG
EXERCICE Année scolaire lié au paiement AN 10 E SIG
Montant débité par
MONTANT_DEBITE l'opérateur pour un paiement N 8 E SIG
NUMTEL Numéro de téléphone débité AN 12 E SIG
OPERATEUR Opérateur lié à la transaction AN 8 E SIG
Numéro de session lié à un
SESSIONID paiement AN 255 CO SIG
Numéro de la transaction lié
TOKEN au paiement AN 255 E SIG
SITE_ID Identifiant de l'établissement N 8 E SIG ID
24
ADRESSE_SITES Adresse de l'établissement AN 50 E SIG
CODE_SITE Code de l'établissement N 8 E SIG
LIBELLE_SITE Libellé de l'établissement AN 200 E SIG
RIB RIB de l'établissement AN 20 E SIG
Numéro de téléphone de
TELEPHONE_SITES l'établissement AN 12 E SIG
Type d'enseignement de
TYPE_SITE l'établissement N 8 E SIG
ID Identifiant de l'utilisateur N 8 E SIG ID
Code d'activation envoyé par
email pour confirmation de
ACTIVATIONCODE l'inscription AN 36 E SIG
ADRESSE_SPERSONNE Adresse de l'utilisateur AN 50 E SIG
CODE_PERSONNE Matricule de l'utilisateur AN 50 E SIG
Etat de confirmation ou non
CONFIRMA d'un utilisateur N 8 E SIG
EMAIL Email de l'utilisateur AN 20 E SIG
NOM_PERSONNE Nom de l'utilisateur AN 100 E SIG
PRENOMS_PERSONNE Prenoms de l'utilisateur AN 100 E SIG

TELEPHONE_PERSONN
E Téléphone de l'utilisateur AN 12 E SIG
USERNAME Login de l'utilisateur AN 50 E SIG
ID_VIREMENT Identifiant du virement N 8 E SIG ID
CODE_ETAB Code de l'établissement N 8 E SIG
DATE_EMISSION Date d'emission du virement AN 15 E SIG
DATE_CONFIRM Date de reception du virement AN 15 E SIG

MONTANT Montant du virement N 8 E SIG
RIB_ETAB RIB de l'établissement AN 20 E SIG
STATUT Etat du virement N 8 E SIG
Utilisateur ayant procédé au
USERNAME virement AN 50 E SIG
A : Alphabétique AN : Alphanumérique N : Numérique
ID : Identifiant CA: Calculée CO: Concaténée
SIG: Signalétique SIT: Situation MVT: Mouvement E : élémentaire
25
26
27
N_ECHEANCE CLASSE
N_PAIEMENT ID_ECHEANCE ID_CLASSE
IDPAIEMENT NUM_ECHEANCE LIBELLE_CLASSE
SESSIONID DATE_ECHEANCE Cle_1 <pi>
NUMTEL MONTANT ...
MONTANT_DEBITE MONTANT_REGLE
TOKEN 0,n
SOLDEAVTPAIEMENT
OPERATEUR SITES
Cle_1 <pi>
DATE_HEURE_ENVOI SITE_ID

...
DATE_HEURE_RECEPTION_TOKEN CODE_SITE
EXERCICE 0,1 Fait Partie LIBELLE_SITE
ETAT Avoir 0,n ADRESSE_SITES
PK_N_PAIEMENT <pi> TELEPHONE_SITES
... TYPE_SITE
0,n 0,1 RIB
0,1 1,1

PK_SITES <pi>
N_INSCRIT ...
Lier
 REPRESENTATION DU MCD
MATRICULE 0,1 0,n

Contient 0,n NOM_ELEVE Appartient
PRENOMS_ELEVE Est dans
EXERCICE
Identifiant_3 <pi>
... 0,1
0,n VIREMENT USERCONFIRM
ID_VIREMENT ID
DATE_EMISSION CODE_PERSONNE
DATE_CONFIRM NOM_PERSONNE
CODE_ETAB PRENOMS_PERSONNE
RIB_ETAB ADRESSE_SPERSONNE
MONTANT TELEPHONE_PERSONNE
STATUT USERNAME
USERNAME CONFIRMA
PK_VIREMENT <pi> ACTIVATIONCODE
... EMAIL
PK_USERCONFIRM <pi>
...
I-2 Modèle conceptuel des traitements (MCT)
I-2.1- Définition
Les traitements constituent la partie dynamique du système d’information. Ils décrivent
les actions à exécuter sur les données afin d’obtenir les résultats attendus par l’entreprise.
Le MCT est la représentation schématique des traitements ou d’un sous ensemble des
traitements à l’intérieur d’une entreprise indépendamment des choix d’organisation et des
moyens d’exécution.
La préoccupation principale du MCT, c’est d’identifier les actions à accomplir. La

question principale c’est « QUOI FAIRE ? ». Le MCT ne prend pas en compte :
 Qui doit le faire?

 Quand l’action se fait-elle ?
 Quelle ressource est nécessaire pour réaliser l’action ?
Le MCT est donc très loin des préoccupations organisationnelles.
I-2.2- Concepts de base
Evènement : Un évènement signale que quelque chose s’est passé. Il correspond à une
sollicitation pour le système d’information et déclenche une réaction de ce dernier par
l’exécution d’une ou plusieurs taches.
Evènement externe : Un évènement externe est un évènement qui prend naissance à

l’extérieur du système d’information et provoque une réaction au sein du système
d’information à l’étude.
Evènement interne : Un évènement interne est un évènement qui prend naissance à l’intérieur
du système d’information à la suite d’une opération. Une opération produit un ou plusieurs
évènements internes.
Evènement temporel : Un évènement temporel est un évènement lié au temps ou à un délai.
Synchronisation d’évènements : La synchronisation est le lieu de rencontre des évènements

(externes et internes) qui permettent le déclenchement d’une opération.
Opération : Une opération est constituée d’une suite d’actions qui sont exécutables sans
interruption selon les règles de gestion.
28
Règles d’émission des résultats : L’émission de résultats par une opération peut être
conditionnée par des règles. Ces règles sont appelés règles d’émission des résultats.
Acteur : Un acteur est émetteur ou récepteur d’un échange. Il peut être interne ou externe.
Flux : Un flux décrit les échanges d’informations entre deux acteurs (un acteur émetteur et un
acteur récepteur).
Processus : C’est un enchainement des opérations qui représente une unité homogène de
préoccupation de l’entreprise.
Diagramme des flux : Le diagramme des flux est le diagramme qui représente les flux circulant
dans le système d’information.
29
I-2.3- Représentation schématique d’un MCT
Evènements
Synchronisation
Opération
Règles
Evènements
 Diagramme des flux
 Les acteurs
Acteur interne : JFR, Opérateur, Banque.
Acteur externe : Parent d’élève, Etablissement.
 Le graphe des flux
Acteur externe :
Acteur interne :
Flux :
30
Processus1 : Identification des établissements(Administrateur) sur la plateforme
2 3
JFR Etablissement
1
1- Demande d’identification (Formulaire d’inscription) d’un utilisateur.

2- Vérification auprès de l’établissement pour l’attribution du droit Administrateur.
3- Attribution du droit Admin.
Processus 2 : Importation des données par établissement
2
JFR Etablissement
1
1- Mise à disposition de la plateforme Web « Frais Scolaires ».

2- Formatage d’un fichier Excel par l’établissement pour importation dans la base.
Processus 3 : Paiement d’un frais de scolarité par un parent
3 4 6
JFR Operateur Parent d’élève
2 7 1 5
1- Parent à l’aide de son téléphone fait une requête (ex : #000#) sur le service.
2- Opérateur envoie le matricule de l’élève renseigné par le parent.
3- JFR renvoie les informations correspondant à ce matricule.
4- L’opérateur renvoie ces informations au parent.
5- Le parent confirme ces informations et renseigne le montant qu’il souhaite payer.
6- L’opérateur renvoie au parent l’effectivité du montant prélevé.
7- L’opérateur notifie JFR du montant prélevé pour le matricule préalablement renseigné.
31
Processus 4 : Demande de Virements bancaires
1 2
JFR Operateur Banque
4 5
Banque JFR Etablissement
3
1- Demande de transfert des fonds vers la banque.

2- Transfert des fonds recueillis par l’opérateur vers la banque.
3- Demande de virements pour les établissements sur base de leur RIB.
4- Confirmation ou non des virements effectués.
5- Mis à jour de la plateforme après passage des virements.
32
 Graphe d’ordonnancement des flux
Processus 1 : Identification des établissements(Administrateur) sur la plateforme
Verification pour l'attribution du

Demande d'identification sur la droit Admin
plateforme Web
Oui Non
Droit d'administration attribué Droit d'administration non attribué
Mis a disposition de la plateforme

par établissement
Formatage d'un fichier excel pour

Fichier Excel conforme
l'importation des élèves.
Oui Non
Succès de l'importation. Données Echec de l'importation

disponibles pour l'utilisation du service.
33
Processus 3 : Paiement du frais de scolarité par un parent
Parent d'élève effectuant la Insertion du matri cule élève.

requete sur son mobile
Interrogation de l a plateforme Web
Matricule retrouvé Matricule inexistant
Retour au parent des informations

concernant le matri cule
Informations non correspondant Confirmation des informations par

le parent
Insertion du montant à payer
Prélèvement effectué Prélèvement non effectué
Mise à jour dans la BD du montant

prélevé pour ce matricule
34
Demande de transfert par

l'operateur vers la banque
Fonds recus par la banque
Requete de virement lancée RIB de l'etablissement valide
Virement effectué Virement non effectué
Oui Non
Mise a jour de la Base de données

Etablissment
35
 Représentation du MCT
Demande d'
identification sur la
plateforme Web
Demande d’identification utilisateur

Verification pour l'
attribution du droit Admin
OK Non Ok
Droit d'
Droit d'
administration
administration
attribué
non attribué
Mis a disposition de la
plateforme par
établissement
Importation des données relatives aux

élèves
Formatage d'un fichier excel pour l'
importation des élèves
Fichier Conforme Fichier non conforme
Succès de l'importation.
Données disponibles pour Echec de l'importation
l'utilisation du service.
36
Insertion du matricule élève

Parent d'élève effectuant la .
ET
Verification
Interrogation de la plateforme Web
Matricule Retrouvé Matricule inexsistant
Retour au parent des

informations concernant le
matricule
Confirmation
Informations non correspondant Informations correspondant
Confirmation des
informations par le
parent
PAIEMENT
Prélèvement effectué Prélèvement non effectué
Mise à jour dans la BD du

montant prélevé pour ce
matricule

37
Demande de
transfert(operateur
vers banque)
Virement 1
Fonds recus par la

banque
ET
Virement 2
Requete de virement lancée
RIB de l'etablissement valide RIB de l'etablissement non valide
Virement effectué et Mise a Virement non effectué

jour de la Base de données
Etablissment
38
II- ETUDE FONCTIONNELLE
II.1- Modèle organisationnel des traitements (MOT)
II.1.1- Définition
Le MOT permet de présenter l’ensemble des traitements en prenant en compte
l’organisation de l’entreprise.
Le MOT répond aux préoccupations suivantes :
 Qui fait l’action et où ?

 Quelle ressource est nécessaire pour effectuer l’action ?
 A quelle période se déroule l’action ?
II.1.2- Concepts de base

Compte tenu des règles d’organisation, les actions d’une même opération peuvent être
affectées à plusieurs postes de travail. Ainsi, une opération au niveau conceptuel (MCT)
correspondra à une ou plusieurs procédures fonctionnelles (PF) au niveau du MOT.
Une PF est constituée d’un ensemble de traitements élémentaires ininterrompus. Elle

correspond à l’exécution par l’entreprise d’un ensemble de règles de gestion produisant un ou
plusieurs résultats.
Une PF appartient à un et un seul processus du MCT.
II.1.2.1- La règle des trois unités
Les PF doivent être déterminées à partir de la décomposition d’une opération du MCT en

respectant la règle des trois unités :
 Unité d’action : Opération ininterruption (s’il y a une unité d’action et une unité
d’acteur).
 Unité de lieu : Un poste de travail.
 Unité de temps : Durée ininterrompue.
 L’opération définie dans le MCT se déroule-t-elle de façon ininterrompue ?
 L’opération définie dans le MCT se déroule-t-elle dans le même endroit ?
 L’opération définie dans le MCT se déroule-t-elle au même moment ?
39
Si pour chacune des questions ci-dessous la réponse est oui, alors une opération du MCT
donne lieu à une seule procédure fonctionnelle dans le MOT.
Dans le cas contraire l’opération du MCT donne lieu à plusieurs procédures

fonctionnelles.
II.1.2.2- Représentation schématique d’un MOT
Période Enchainement des procédures fonctionnelles Nature de Poste de

la PF travail
Evènement
Synchronisation
Opération
Règles
Evènements
Nature d’une procédure fonctionnelle
MA : Manuel
A : Automatique
ATR : Automatique Temps Réel
ATD : Automatique Temps Différé
AC : Automatique Conventionnel
AB : Automatique Batch
 Manuel (MA) : Une PF qui peut s’exécuter entièrement sans l’aide de l’ordinateur est
dite manuelle.
40
 Automatique (Temps Différé ou « Batch » : ATD ou AB): C’est une procédure qui va
donner lieu à un algorithme aboutissant à un programme exécutable par l’ordinateur.
Ce type de programme s’exécute du début à la fin sans intervention humaine.
L’intervention humaine est limitée au seul lancement du programme.
 Automatique (Temps réel ou conventionnel : ATR ou AC) : C’est une procédure qui va
donner lieu à un algorithme aboutissant à un programme exécutable par l’ordinateur.
L’exécution d’un tel programme se déroule sous la forme d’un dialogue (conversation)
entre l’homme et la machine.
Période Enchainement des procédures fonctionnelles Nature de la Poste de

PF travail
Avant
l’adhésio Demande d'
identification sur la
Automatiqu Etablissemen
n au
plateforme Web e t
service
Frais
Scolaires
Demande d’identification utilisateur
Verification pour l'
attribution du droit Admin Manuel JFR-SYSTEMS
OK Non Ok
Après Droit d' Droit d'

l'analyse administration administration Automatiqu JFR-SYSTEMS
attribué non attribué
de la e
demande
41

PF travail
Dès
l’attribution
Mis a disposition de la
du droit plateforme par Automatique JFR
établissement
d’administr
ation
Importation des données relatives aux

élèves
Avant la
Formatage d'un fichier excel pour l'
procédure importation des élèves
Fichier Conforme Fichier non conforme Automatique Etablisse
de
ment
paiement
des
Succès de l'importation.
parents Données disponibles pour Echec de l'importation
l'utilisation du service.
d’élèves
42
Période Enchainement des procédures fonctionnelles Nature de la PF Postede travail
43
Insertion du matricule élève
Parent d'élève effectuant la .
Automatique Opérateur
ET
Verification
Interrogation de la plateforme Web
Matricule Retrouvé Matricule inexsistant Automatique JFR
Demande de
paiement de
Retour au parent des
frais de informations concernant le
scolarité matricule Automatique Opérateur
Confirmation
Informations non correspondant Informations correspondant

Automatique Parent
Confirmation des
informations par le
parent
PAIEMENT
Prélèvement effectué Prélèvement non effectué Automatique Opérateur
Mise à jour dans la BD du

montant prélevé pour ce
matricule Automatique JFR
44
PF travail
Demande de
transfert(operateur Automatique JFR
vers banque)
Virement 1
A une
fréquence
de 2 Automatique Banque
semaines,
les
virements Fonds recus par la
banque
doivent
être
effectués
ET
Virement 2
Requete de virement lancée
RIB de l'etablissement valide RIB de l'etablissement non valide
Automatique JFR
Virement effectué et Mise

a jour de la Base de Virement non effectué
données Etablissment
45
II.2- Modèle logique de données (MLD)
CLASSE (ID_CLASSE, LIBELLE_CLASSE).
N_ECHEANCE (ID_ECHEANCE, NUM_ECHEANCE, DATE_ECHEANCE, MONTANT,

MONTANT_REGLE, SOLDEAVTPAIEMENT, #MATRICULE).
N_INSCRIT (MATRICULE, SITE_ID, NOM_ELEVE, PRENOMS_ELEVE, EXERCICE, #ID_CLASSE).
N_PAIEMENT (IDPAIEMENT, SESSIONID, NUMTEL, MONTANT_DEBITE, TOKEN, OPERATEUR,

DATE_HEURE_ENVOI, DATE_HEURE_RECEPTION_TOKEN, EXERCICE, ETAT, #ID_VIREMENT,
#MATRICULE).
SITES (SITE_ID, CODE_SITE, LIBELLE_SITE, ADRESSE_SITES, TELEPHONE_SITES, TYPE_SITE, RIB).
USERCONFIRM (ID, CODE_PERSONNE, NOM_PERSONNE, PRENOMS_PERSONNE,

ADRESSE_SPERSONNE, TELEPHONE_PERSONNE, USERNAME, CONFIRMA, ACTIVATIONCODE,
EMAIL, #SITE_ID).
VIREMENT (ID_VIREMENT, DATE_EMISSION, DATE_CONFIRM, CODE_ETAB, RIB_ETAB,

MONTANT, STATUT, USERNAME).
46
III- ETUDE ORGANIQUE
Modèle physique de données (MPD)
Script de création de la base de données

/*==============================================================*/
/* Table: CLASSE */
/*==============================================================*/
create table CLASSE (
ID_CLASSE int not null,
LIBELLE_CLASSE varchar(50) null,
constraint PK_CLASSE primary key nonclustered (ID_CLASSE)
)
go
/*==============================================================*/
/* Table: N_ECHEANCE */
/*==============================================================*/
create table N_ECHEANCE (
ID_ECHEANCE int not null,
MATRICULE varchar(20) collate SQL_Latin1_General_CP1_CI_AS null,
NUM_ECHEANCE int null,
DATE_ECHEANCE datetime null,
MONTANT float null,
MONTANT_REGLE float null,
SOLDEAVTPAIEMENT float null,
constraint PK_N_ECHEANCE primary key nonclustered (ID_ECHEANCE)
)
go
/*==============================================================*/
/* Table : N_INSCRIT */
/*==============================================================*/
create table N_INSCRIT (
MATRICULE varchar(20) collate SQL_Latin1_General_CP1_CI_AS not null,
ID_CLASSE int null,
SITE_ID int null,
NOM_ELEVE varchar(100) collate SQL_Latin1_General_CP1_CI_AS null,
PRENOMS_ELEVE varchar(100) collate SQL_Latin1_General_CP1_CI_AS null,
EXERCICE int null,
47
constraint PK_N_INSCRIT primary key nonclustered (MATRICULE)
)
go
/*==============================================================*/
/* Table : N_PAIEMENT */
/*==============================================================*/
create table N_PAIEMENT (
IDPAIEMENT numeric identity(1, 1),
ID_VIREMENT int null,
MATRICULE varchar(20) collate SQL_Latin1_General_CP1_CI_AS not null,
SESSIONID varchar(255) collate SQL_Latin1_General_CP1_CI_AS null,
NUMTEL varchar(12) collate SQL_Latin1_General_CP1_CI_AS null,
MONTANT_DEBITE float null,
TOKEN varchar(255) collate SQL_Latin1_General_CP1_CI_AS null,
OPERATEUR varchar(8) collate SQL_Latin1_General_CP1_CI_AS null,
DATE_HEURE_ENVOI datetime null,
DATE_HEURE_RECEPTION_TOKEN datetime null,
EXERCICE int null,
ETAT int null constraint DF_N_PAIEMENT_ETAT default (0),
constraint PK_N_PAIEMENT primary key nonclustered (IDPAIEMENT)
)
go
/*==============================================================*/
/* Table : SITES */
/*==============================================================*/
create table SITES (
SITE_ID int not null,
CODE_SITE int null,
LIBELLE_SITE varchar(200) collate SQL_Latin1_General_CP1_CI_AS null,
ADRESSE_SITES varchar(50) collate SQL_Latin1_General_CP1_CI_AS null,
TELEPHONE_SITES varchar(12) collate SQL_Latin1_General_CP1_CI_AS null,
TYPE_SITE int null,
RIB int null,
constraint PK_SITES primary key nonclustered (SITE_ID)
)
go
/*==============================================================*/
/* Table : USERCONFIRM */
/*==============================================================*/
create table USERCONFIRM (
ID numeric identity(1, 1),
48
SITE_ID int null,
CODE_PERSONNE varchar(50) collate SQL_Latin1_General_CP1_CI_AS null,
NOM_PERSONNE varchar(100) collate SQL_Latin1_General_CP1_CI_AS null,
PRENOMS_PERSONNE varchar(100) collate SQL_Latin1_General_CP1_CI_AS null,
ADRESSE_SPERSONNE varchar(100) collate SQL_Latin1_General_CP1_CI_AS null,
TELEPHONE_PERSONNE varchar(12) collate SQL_Latin1_General_CP1_CI_AS null,
USERNAME varchar(50) collate SQL_Latin1_General_CP1_CI_AS null,
CONFIRMA int null constraint DF_USERCONFIRM_CONFIRMA default (0),
ACTIVATIONCODE varchar(36) null,
EMAIL varchar(20) collate SQL_Latin1_General_CP1_CI_AS null,
constraint PK_USERCONFIRM primary key nonclustered (ID)
)
go
/*==============================================================*/
/* Table : VIREMENT */
/*==============================================================*/
create table VIREMENT (
ID_VIREMENT numeric identity(1, 1),
DATE_EMISSION datetime null,
DATE_CONFIRM datetime null,
CODE_ETAB int null,
RIB_ETAB varchar(20) null,
MONTANT float null,
STATUT int null constraint DF_VIREMENT_STATUT default (0),
USERNAME varchar(50) collate SQL_Latin1_General_CP1_CI_AS null,
constraint PK_VIREMENT primary key nonclustered (ID_VIREMENT)
)
go
49
QUATRIEME PARTIE : DEPLOIEMENT ET INTEGRATION
QUATRIEME PARTIE :
DEPLOIEMENT ET
INTEGRATION
50
I- ETUDE TECHNIQUE ET PRESENTATION DES PLATEFORMES
ATTAQUES
I.1-Plateforme USSD
Le protocole de communication utilisé est REST. Il permet l’interaction et l’échange de
données entre deux systèmes hétérogènes.
Ce protocole est utilisé pour faciliter les opérations de consultation de facture et de paiement
de facture.
Figure: Diagramme général des flux entre « Frais Scolaires » et l’abonné
I.2-Plateforme Web
L’architecture logicielle décrit d’une manière symbolique et schématique les différents
composants d’un ou de plusieurs systèmes informatiques, leurs points de fusionnement et leurs
interactions. Contrairement aux spécifications produites par l’analyse fonctionnelle, le modèle
d'architecture, produit lors de la phase de conception, ne décrit pas ce que doit réaliser un
système informatique mais plutôt comment il doit être conçu de manière à répondre aux
spécifications. L’analyse décrit le quoi faire alors que l’architecture décrit le comment le faire.
Elle a énormément évolué pour s’adapter aux nouvelles contraintes de développement. De
l’architecture à deux parties (client–serveur classique), l’on est aujourd’hui aux architectures
multi niveau (n-tiers).
51
1- Client-serveur
La première génération d’architecture logicielle est composée de deux parties : le

serveur et le client. L'architecture client/serveur désigne un mode de communication entre
plusieurs ordinateurs d'un réseau qui distingue un ou plusieurs clients du serveur : chaque
logiciel client peut envoyer des requêtes à un serveur. Un serveur peut être dédié aux
applications, fichiers, ou encore de messageries électroniques. Ses principaux atouts sont :
 des ressources centralisées : étant donné que le serveur est un dispositif
informatique matériel ou logiciel qui offre des services, à différents clients au centre
du réseau, il peut gérer des ressources communes à tous les utilisateurs, afin d'éviter
les problèmes de redondance et de contradiction ;
 une meilleure sécurité : car le nombre de points d'entrée permettant l'accès aux
données est moins important ;
 une administration au niveau serveur : les clients envoyant seulement des requêtes
vers le serveur dans ce modèle, ils ont moins besoin d'être administrés ;
 un réseau évolutif : grâce à cette architecture il est possible de supprimer ou
rajouter des clients sans perturber le fonctionnement du réseau et sans modification
majeure.
Bien que cette architecture offre de nombreux avantages, elle présente de grosses insuffisances
que l’on peut résumer en ces points :
 un coût élevé dû à la technicité du serveur ;
 un maillon faible : le serveur est le seul maillon faible, car tout le réseau est
architecturé autour de lui ;
 le client est lourd : il faut des machines performantes pour exécuter les applications ;
 le client est propriétaire : une mise à jour de toute application épousant cette
architecture nécessite une mise à jour sur chaque les postes clients.
52
Schéma d'une architecture Client-Serveur
2- Architecture à trois niveaux
Afin de décharger le serveur et répartir les tâches, un troisième niveau a été rajouté à
l’architecture précédente pour créer la deuxième génération d’architecture logicielle.
L'architecture trois-tiers (de l'anglais tiers signifiant étage ou niveau) est un modèle logique
d'architecture applicative qui vise à séparer très nettement trois couches logicielles au sein
d'une même application ou système, à modéliser et présenter cette application comme un
empilement de trois couches, étages, niveaux ou strates dont le rôle est clairement défini :
 La présentation des données : correspondant à l'affichage, la restitution sur le

poste de travail, le dialogue avec l'utilisateur ;
 Le traitement métier des données : correspondant à la mise en œuvre de
l'ensemble des règles de gestion et de la logique applicative ;
 L’accès aux données persistantes : correspondant aux données qui sont destinées à
être conservées sur la durée, voire de manière définitive.
Schéma d'une architecture à trois niveaux
3- Architecture à n-tiers (Architecture répartie)
L'architecture n-tiers a été pensée pour pallier aux limitations des architectures trois
tiers, concevoir des applications puissantes et simples à maintenir. Ce type d'architecture
permet de distribuer plus librement la logique applicative, ce qui facilite la répartition de la
charge entre tous les niveaux.
53
Cette évolution des architectures trois tiers met en œuvre une approche objet pour offrir une
plus grande souplesse d'implémentation et faciliter la réutilisation des développements.
Théoriquement, ce type d'architecture supprime tous les inconvénients des architectures

précédentes :
 elle permet l'utilisation d'interfaces utilisateurs riches ;
 elle sépare nettement tous les niveaux de l'application ;
 elle offre de grandes capacités d'extension ;
 elle facilite la gestion des sessions.
Une architecture n-tiers comprend généralement une couche de présentation, une couche de
services et d'objets métier et une couche d'accès aux données.
Schéma d'une architecture à n-tiers
4- Architecture MVC
Le Modèle-Vue-Contrôleur (en abrégé MVC, de l'anglais Model-View-Controller) est une

architecture et une méthode de conception qui organise l'interface homme-machine (IHM)
d'une application logicielle. Ce paradigme divise l'IHM en un modèle (modèle de données), une
vue (présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion des
événements, synchronisation), chacun ayant un rôle précis dans l'interface. Cette méthode a
été mise au point en 1979 par Trygve Reenskaug.
54
Schéma d'une architecture MVC
L'organisation globale d'une interface graphique est souvent délicate. L'architecture MVC ne
résout pas tous les problèmes. Elle fournit souvent une première approche qui peut ensuite
être adaptée. Elle offre aussi un cadre pour structurer une application.
Ce modèle d'architecture impose la séparation entre les données, la présentation et les

traitements. Ce qui donne trois parties fondamentales dans l'application finale : le modèle, la
vue et le contrôleur.
a- Le Modèle
Le modèle représente le comportement de l'application : traitements des données,

interactions avec la base de données, etc. Il décrit ou contient les données manipulées par
l'application. Il assure la gestion de ces données et garantit leur intégrité. Dans le cas typique
d'une base de données, c'est le modèle qui la contient. Le modèle offre des méthodes pour
mettre à jour ces données (insertion, suppression, changement de valeur).
Il offre aussi des méthodes pour récupérer ces données. Les résultats renvoyés par le modèle
sont dénués de toute présentation.
55
b- La vue
La vue correspond à l'interface avec laquelle l'utilisateur interagit. Sa première tâche est
de présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes les
actions de l'utilisateur (clic de souris, sélection d'une entrée, boutons, etc.). Ces différents
événements sont envoyés au contrôleur. La vue n'effectue aucun traitement, elle se contente
d'afficher les résultats des traitements effectués par le modèle et d'interagir avec l'utilisateur.
Elle peut être conçue en HTML ou tout autre marquage de présentation.
c- Le contrôleur
Le contrôleur prend en charge la gestion des événements de synchronisation pour

mettre à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de
l'utilisateur et enclenche les actions à effectuer. Si une action nécessite un changement des
données, le contrôleur demande la modification des données au modèle, ce dernier avertit la
vue que les données ont changée pour qu'elle se mette à jour. Certains événements de
l'utilisateur ne concernent pas les données mais la vue. Dans ce cas, le contrôleur demande à la
vue de se modifier. Le contrôleur n'effectue aucun traitement, ne modifie aucune donnée. Il
analyse la requête du client et se contente d'appeler le modèle adéquat et de renvoyer la vue
correspondant à la demande.
Par exemple, dans le cas d'une base de données gérant les emplois du temps des professeurs
d'une école, une action de l'utilisateur peut être l'entrée (saisie) d'un nouveau cours. Le
contrôleur ajoute ce cours au modèle et demande sa prise en compte par la vue. Une action de
l'utilisateur peut aussi être de sélectionner une nouvelle personne pour visualiser tous ses
cours. Ceci ne modifie pas la base des cours mais nécessite simplement que la vue s'adapte et
offre à l'utilisateur une vision des cours de cette personne.
Quand un même objet contrôleur reçoit les événements de tous les composants, il lui faut
déterminer quelle est l'origine de chaque événement. Ce tri des événements peut s'avérer
fastidieux et peut conduire à un code pas très élégant. C'est pourquoi le contrôleur est souvent
scindé en plusieurs parties dont chacune reçoit les événements d'une partie des composants.
5- Choix de l’architecture logiciel
Pour la réalisation de notre application, notre choix a été porté sur le type d'architecture
"Architecture à trois niveaux".
56
Vu que les utilisateurs sont situés dans des lieux distincts, équipés d’infrastructures techniques
différentes, vu aussi le nombre important d’accès au serveur il est important d’utiliser cette
architecture de sorte à optimiser au mieux les différentes requêtes qui seront soumises.
Ce type d’architecture a besoin de se déterminer sur les points suivants :
 choix de la technologie de développement Web ;

 choix de la base de données ;
 choix de l’environnement de développement.
II- REALISATION
II.1-Présentation des outils et langages utilisés
II.1.1-Microsoft Visual Studio 2010

Microsoft Visual Studio est une suite de logiciels de développement pour Windows
conçue par Microsoft. La dernière version en date s'appelle Visual Studio 2013.
Visual Studio est un ensemble complet d'outils de développement permettant de
générer des applications Web ASP.NET, des Services Web XML, des applications bureautiques et
des applications mobiles. Visual Basic, Visual C++, Visual C# et Visual J# utilisent tous le même
environnement de développement intégré (IDE, Integrated Development Environment), qui
leur permet de partager des outils et facilite la création de solutions faisant appel à plusieurs
langages. Par ailleurs, ces langages permettent de mieux tirer parti des fonctionnalités du
Framework .NET, qui fournit un accès à des technologies clés simplifiant le développement
d'applications Web ASP et de Services Web XML grâce à Visual Web Developer.
Microsoft Visual Studio 2010 est sortie en version finale le 12 avril 2010. Cette nouvelle
version utilise la version 4.0 du .NET Framework dans le logiciel ainsi qu'une refonte de
l'interface graphique propulsée par WPF.
À cette occasion, le logo a changé, pour une version plus "moderne". Les différentes
déclinaisons de Visual Studio ont elles aussi changé de nom par souci de clarification de l'offre.
Le numéro de version interne de Visual Studio 2010 est 10.0
57
II.1.2-Microsoft SQL Server 2008 R2
Microsoft SQL Server est un système de gestion de base de données (abrégé en SGBD
ou SGBDR pour « Système de gestion de base de données relationnelles ») développé et
commercialisé par la société Microsoft.
Bien qu'il ait été initialement Co développé par Sybase et Microsoft, Ashton-Tate a
également été associé à sa première version, sortie en 1989. Cette version est sortie sur les
plates-formes Unix et OS/2. Depuis, Microsoft a porté ce système de base de données
sous Windows et il est désormais uniquement pris en charge par ce système.
En 1994, le partenariat entre les deux sociétés ayant été rompu, Microsoft a sorti la
version 6.0 puis 6.5 seul, sur la plate-forme Windows NT.
 Microsoft a continué de commercialiser le moteur de base de données sous le nom de

SQL Server ;
 Tandis que Sybase, pour éviter toute confusion, a renommé Sybase SQL Server en
Sybase Adaptive Server Enterprise.
Microsoft SQL Server fait désormais partie de la stratégie technique de Microsoft en
matière de base de données. Le moteur MSDE, qui est la base de SQL Server, doit à terme
remplacer le moteur Jet (celui qui gère les bases Access) dans les applications telles
que Exchange et Active Directory.
La version 2005 de SQL Server est sortie le 3 novembre 2005 en même temps que Visual
Studio 2005. La prise en charge de Windows Vista et de Windows Server 2008 n'a été ajoutée
qu'à partir du Service Pack 2 (SP2). Actuellement le Service Pack 3 est disponible.
La version 2008 de SQL Server (nom de code Katmaï) est disponible depuis août 2008.
Elle est actuellement au niveau de service pack 3. Elle est disponible en 9 langues, dont le
français.
La version 2012 de SQL Server est disponible depuis avril 2012.
II.1.3- Le langage C#
Le C♯ est un langage de programmation orienté objet à typage fort, créé par la
société Microsoft, et notamment un de ses employés, Anders Hejlsberg, le créateur du
langage Delphi.
Il a été créé afin que la plate-forme Microsoft .NET soit dotée d'un langage permettant
d'utiliser toutes ses capacités. Il est très proche du Java dont il reprend la syntaxe générale ainsi
que les concepts (la syntaxe reste cependant relativement semblable à celle de langages tels
58
que le C++ et le C). Un ajout notable au C# est la possibilité de surcharge des opérateurs,
inspirée du C++. Toutefois, l'implémentation de la redéfinition est plus proche de celle du Pascal
Objet.
II.1.4- Asp.net
ASP.NET 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) ou à l'intérieur de Visual Web Developer
Express Edition ou ASPNET Web Matrix.
ASP.NET fait partie de la plateforme Microsoft .NET et est le successeur de la
technologie Active Server Pages (ASP).
II.1.5-DevExpress
DevExpress (Developer Express Inc.) est une société de développement de logiciels
fondée en 1998 dont le siège est à Glendale, en Californie. DevExpress a d'abord commencé à
produire des contrôles d'interface utilisateur pour Borland Delphi / C ++ Builder et les contrôles
ActiveX pour Microsoft Visual Studio. Actuellement, DevExpress a des produits ciblant les
développeurs qui utilisent Delphi / C ++ Builder, Visual Studio et HTML5 / JavaScript
technologies.
II.1.6- Le langage JAVA

Le langage Java est un langage de programmation informatique orienté objet créé
par James Gosling et Patrick Naughton, employés de Sun Microsystems, avec le soutien de Bill
Joy (cofondateur de Sun Microsystems en 1982), présenté officiellement
le 23 mai 1995 au SunWorld.
La société Sun a été ensuite rachetée en 2009 par la société Oracle qui détient et maintient
désormais Java.
La particularité et l'objectif central de Java est que les logiciels écrits dans ce langage doivent
être très facilement portables sur plusieurs systèmes d’exploitation tels
que UNIX, Windows, Mac OS ou GNU/Linux, avec peu ou pas de modifications. Pour cela,
divers plateformes et frameworks associés visent à guider, sinon garantir, cette portabilité
des applications développées en Java.
59
II.1.7-Eclipse
Eclipse est un projet, décliné et organisé en un ensemble de sous-projets de
développements logiciels, de la Fondation Eclipse visant à développer un environnement de
production de logiciels libre qui soit extensible, universel et polyvalent, en s'appuyant
principalement sur Java.
Son objectif est de produire et fournir des outils pour la réalisation de logiciels, englobant les
activités de programmation (notamment environnement de développement
intégré et frameworks) mais aussi d'AGL recouvrant modélisation, conception, testing, gestion
de configuration, reporting… Son EDI, partie intégrante du projet, vise notamment à supporter
tout langage de programmation à l'instar de Microsoft Visual Studio.
II.2- Présentation des fonctionnalités
II.2.1- Liste des fonctionnalités à mettre en œuvre
Le système à mettre en place tel que décrit dans le cahier des charges devra permettre
d’effectuer les actions suivantes :
II.2.1.1- Module (plateforme) dédiée à la mise en exploitation

et au suivi du bon fonctionnement des opérations de paiements électroniques
Cette plateforme Web sera mise à disposition des établissements souhaitant utilisées le service
frais scolaires. Elle leur permettra entre autres de :
o Gérer les différents accès suivant des profils que sont : Directeur, Informaticien et
Administrateur ;
o Permettre l’importation des élèves via un fichier Excel suivant un format prédéfini ;
o Consulter les différents paiements effectués ;
o Consulter les échéances et leur paiement par élève ;
o Consulter l’état des virements effectués sur leur compte.
II.2.1.2- Module pour le service USSD
Ce module servira de ‘’pont’’ entre les données de la plateforme web(API) et les opérateurs
téléphoniques. Le service USSD permettra
60
o Aux opérateurs d’afficher aux parents d’élèves sollicitant le service les messages
adéquats ;
o Aux opérateurs de nous faire un retour sur l’effectivité ou non d’une transaction.
II.2.1.3- Module (API) pour l’échange d’informations entre la

plateforme établissement et le service USSD
L’API, à mettre à disposition du service USSD, devra permettre :
o Au service USSD de recueillir des informations (Nom, Prénoms, Niveau, Echéanciers…)

concernant un élève après saisie du matricule ;
o Au service USSD de mettre à jour la base de données concernant une transaction
effectuée (Montant payé, échéance à incrémenter, solde de l’élève…).
II.2.1.4- Module Administrateur pour le virement des

montants recueillis pour chaque établissement
Ce module sera hébergé sur la plateforme web avec un profil « SupraAdmin » qui lui
verra tous les établissements ayant souscris au service Frais Scolaires. Il permettra à une
fréquence donnée d’extraire de la plateforme dans un fichier Excel l’état d’avancement des
paiements par établissement (Montant à virer par établissement).
Ce fichier sera dans un format prédéfini par la banque Hôte et sera importé sur la plateforme
web de celle-ci (banque).
Une fois les montants virés, la base de données Etablissement sera mise à jour.
II.2.2- Description de la mise en œuvre des fonctionnalités

Après la demande d’adhésion au service Frais Scolaires, l’administrateur remplit un

formulaire d’identification sur la plateforme. Le SupraAdmin lui octroie les droits
d’Administration pour l’établissement concernée.
L’administrateur établissement peut dès lors attribuer des droits aux utilisateurs concernant
uniquement son établissement. Ces droits sont : Informaticien, Directeur ou encore
Administrateur.
61
L’informaticien se charge de formater le fichier Excel suivant les colonnes (matricule, nom,
prenoms, niveau, echeance1, date1, montant1, echeance2, date2, montant2, echeance3,
date3, montant3, echeance4, date4, montant4, echeance5, date5, montant5, echeance6,
date6, montant6).
Le directeur aura une vue sur les paiements, les transactions, les virements effectués
concernant son établissement.
Le service USSD est accessible « http://ussd-jfr.herokuapp.com/ ».
o Paramètres attendus : mobile, sessionId, type, message, operator, sequence,

clientStep, serviceCode.
o Paramètres retournés : type, message, clientStep.
Description des paramètres
#clientStep : sert à définir l’écran à afficher à l’utilisateur.
Différentes valeurs de clientStep :
1 : Etape de Récupération du matricule ;
2 : Etape de Récupération du montant payé ;
3 : Etape de Récupération du code du client ;
4 : Etape de Récupération du montant.
#mobile : Indique le numéro de téléphone du client.
#sessionId : Numéro de session attribué pour un parcours client.
#Operator : Identifiant de l’opérateur.
#type : Indique le type d’écran à afficher à l’utilisateur
Différentes valeurs de type :
Initiation : Indiquer à l'application USSD que nous sommes au premier écran du

programme USSD, celui-ci retourne le message à afficher à l'utilisateur
Release : L'application USSD indique un retour d'information qui se trouve dans

#message de la réponse.
62
Response : Mettre le type à Response comme valeur indique que l'utilisateur devra
entrer une valeur. Cette valeur entrée par l'utilisateur devra être ajoutée comme valeur
à message dans le JSON.
#message : Indique le message (texte) à afficher à l’utilisateur.
Message : L'application USSD interprète message comme étant la valeur saisie par l'utilisateur.

Mais dans la Réponse de l'application USSD, message est l'information à afficher à l'écran de
l'utilisateur.
L’opérateur communique avec l'application USSD par des appels HTTP avec la méthode POST.
Exemple du Corps de la REQUETE :
-d : " {"mobile":"+2250000000", "sessionId":"9900093223", "type”: Initiation",

"message":"","operator":"","sequence":1,"clientStep":"0", "serviceCode":"233445"}"
Le retour se fera en format JSON.
Reponse: JSON
Content-Type : "application/json"
-body :"{"type":"", "message":"", "clientStep": step }".
II.2.2.3- Module (API) pour l’échange d’informations entre la

plateforme établissement et le service USSD
Le web service comprend deux méthodes que sont :
 GetInfo
 ProcessDone
La première GetInfo a pour but de ramener les informations (Nom, Classe, Echéanciers…)
concernant un élève.
La seconde ProcessDone a pour but de confirmer ou non que la transaction s’est effectuée sans
encombre.
Le retour de ces méthodes est dans un format JSON.
 GetInfo est accessible via l’URL suivante :

63
https://www.educativespace.net/eschoolfees/api/SchoolFeesService.asmx?op=GetInfo
Vous recevrez en retour après passage du matricule en paramètre :
 le matricule,
 le nom&Prénoms de l'élève,
 l' Id de session ,
 le libellé de l'établissement,
 la classe,
 le solde
 enfin dans une liste les échéances (Montant et Date) liées à cet élève.
Recap :
o Paramètres attendus : matricule

o Paramètres retournés : statusCode, statusMessage, matricule, nom, session,
etablissement, classe, solde, echeances (dans un tableau).
o statusCode : 100=> matricule inexistant en base ; statusCode : 200=> matricule
existant en base
 ProcessDone est accessible via l’URL suivante :
https://www.educativespace.net/eschoolfees/api/SchoolFeesService.asmx?op=ProcessDone
Nous souhaiterions avoir comme retour dans la mesure du possible les informations suivantes :
 l’Id de session que vous recevrez après interrogation du matricule sur la

plateforme Frais Scolaires.
 le numéro de téléphone du client souscrivant au service.
 l'ID de la transaction Orange Money
 et enfin le montant ayant été débité de son compte Orange Money.
Recap :
o Paramètres attendus : SessionID, numero, IdTransaction, Montant

o statut : 'Done' => Processus validé ; statut : 'Failed'=> Échec de validation
du Processus

64
Il sera créé un profil SupraAdmin qui permettra à une fréquence de deux semaines
d’extraire un fichier Excel faisant le point des virements à effectuer par établissement. Ce fichier
sera formaté et inséré sur la plateforme mise à disposition par la banque.
La banque assurant l’effectivité des virements au bout de deux jours maximum, le profil
SupraAdmin repassera sur chacun des virements pour validation. Ceci aura pour conséquence
de mettre à jour sur le profil établissement sur les situations financières.
II.2.3- Résultat des fonctionnalités mises en œuvre

 Connexion à la plateforme Frais Scolaires
Pour accéder à la plateforme « frais-scolaires » saisir dans la barre d’adresse l’url :

http://www.educativespace.net/eschoolfees/.
 S’inscrire
Pour se connecter à la
plateforme « Frais Scolaires » il
faut s’inscrire au préalable.
Pour s’inscrire :
cliquer sur le lien
65
Remplir le formulaire
d’identification
Puis cliquer sur
Un message vous invitant à

consulter votre mail s’affiche.
 Activation du compte
Vous recevez un mail vous

invitant à cliquer sur un lien afin
d’activer votre compte.
Après avoir cliqué sur le lien
« Cliquer ici », vous êtes redirigés
vers la plateforme frais-scolaires.
Un message s’affiche vous
demandant de vous rapprocher
de l’administrateur de votre
établissement.
66
 Connexion
Dès que votre compte est

activé, vous pouvez vous
connecter en renseignant votre
identifiant et votre mot de
passe puis cliquer sur « se
connecter ».
 Présentation de l’interface du profil Administrateur-Ecole
 Importation des élèves
Les fonctionnalités
relatives au profil
Administrateur-Ecole
se résument dans les
Lemenus :
lien importation des
Paramétrages
élèves permet
Sécurité la liste des
d’importer
Utilisateurs
élèves ainsi que leur
échéancier(consultation
Supports par niveau.
d’un support d’aide en
ligne)
L’importation se fera à
partir du bouton
parcourir.
67
Après avoir cliqué sur le bouton
« parcourir », vous êtes emmenés à
aller chercher le fichier contenant la
liste des élèves et leurs échéanciers
sur votre ordinateur.
-sélectionner le fichier puis cliquer

sur « ouvrir »
Après avoir cliqué sur le bouton
« parcourir », vous êtes emmenés à
aller chercher le fichier contenant la
liste des élèves et leurs échéanciers
sur votre ordinateur.
-sélectionner le fichier puis cliquer

sur « ouvrir »
-puis cliquer sur « importer »

68
Le format du fichier Excel est le suivant :
Premier écran d’accès au service Informations retournées sur l’élève
69
Ecran pour la saisie du montant à payer

Vous sélectionnez pour cette

étape la période pour laquelle
vous souhaitez effectuer
l’extraction pour le virement.
Les paiements qui n’auront
pas fait l’objet de virement
pour cette période seront
extraits dans un fichier.
La liste de tous les virements
ainsi que leur état est affichée
dans une grille de données.
70
III- DEPLOIEMENT DE LA SOLUTION
III.1-Description de l'environnement de déploiement
L'application web sera déployée sur IIS. IIS (Internet Information Service) est un Serveur
Web. IIS offre un support pour plusieurs technologies Web telles le ASP et le CGI. Les versions
plus récentes du logiciel sont également compatibles avec le nouveau format de Microsoft, soit
le .NET. Avec les extensions appropriées, il peut aussi héberger des applications écrites en PHP.
Le service USSD quant à lui sera déployé sur Heroku. Heroku est un service de cloud
computing de type Paas (Platform as a Service : environnement d’exécution dans le cloud). Créé
en 2007 puis racheté par Salesforce.com, ce service permet le déploiement rapide
d’applications web dans le cloud.
III.2- Les procédures de déploiement mise en place
III.2.1- Application Web
Créer un nouveau site ;
Entrez le nom du site, le chemin d'accès, et le port de l'application ;

71
Allez dans pool d'application => Paramètres avancés, vérifier si le Pool d'application du
site utilise le FrameWork V4 ;
En cas de modification redémarrer le pool d'application et l'application.
III.2.2- Service USSD
Installer le Heroku Toolbelt ;

Cet outil vous donne accès à l'interface de ligne de commande Heroku (CLI), qui peut être utilisé
pour la gestion et l'élargissement de vos applications ;
Le lien de téléchargement est le suivant : https://devcenter.heroku.com/articles/getting-
started-with-java#set-up
Une fois installé, vous pouvez utiliser la commande heroku de votre shell de commande.
72
Sur Windows, démarrez l'invite de commande (cmd.exe) ;
Ensuite, se connecter en utilisant l'adresse e-mail et mot de passe utilisé lors de la création de
votre compte Heroku :
Déploiement du projet ;
Créer une application sur Heroku, qui prépare Heroku pour recevoir votre code source:
Pour déployer l’application, naviguer vers le répertoire de l’application et lancez la commande:

git push heroku master.
L'application est ainsi déployée.
73
IV- SECURITE
IV.1- Définition des profils utilisateurs
Les fonctionnalités de la solution sont accessibles conformément au profil de connexion
attribué à l’utilisateur. Les profils ne sont pas fixes et donc peuvent être ajoutés au besoin.
Néanmoins quatre catégories majeures peuvent être distinguées :
IV.1.1- Le profil Administrateur
Les administrateurs ont accès à toutes les fonctionnalités du système. Ils effectuent des
modifications affectant d'autres utilisateurs. Ils peuvent par exemple créer, modifier et même
supprimer des utilisateurs, leur accorder des droits ou les révoquer (Notamment les droits
administrateur-école). Ils sont aussi chargés d’enclencher le processus de virements dans les
comptes bancaires des établissements.
IV.1.2- Le profil Administrateur-Ecole
Les Administrateur-Ecole ont les mêmes attributions que celles des administrateurs
généraux. Sauf que toutes ses attributions se limitent au niveau de son école. Ils peuvent donc
dans leur établissement créer, modifier et même supprimer des utilisateurs, leur accorder des
droits (Administrateur-Ecole, Directeur, Informaticien) ou les révoquer.
IV.1.3- Le profil Informaticien
Les informaticiens ont pour principale attribution l’enrichissement de la base de

données des élèves (Nom, prénoms, niveau, Echéancier…). Ils le feront par formatage et
importation d’un fichier Excel.
IV.1.4- Le profil Directeur
Les directeurs pourront consulter sur leur profil l’état d’avancement des paiements par
élève, mais aussi le statut(En attente, Virement passé) des virements qui devront être effectués
sur leurs comptes bancaires. Ils auront une vue plus claire sur les montants recueillis par élève
et donc pour tout l’établissement.
74
IV.2- Authentification des utilisateurs
Il est important pour un site internet de gérer l’identification de ses utilisateurs
ainsi que les autorisations.
Authentifier des utilisateurs permet d’autoriser l’accès à aux ressources de

votre application, qu’à certaines personnes ou proposer des services/fonctionnalités
supplémentaires à des personnes privilégiées (Administrateur, Admin-Ecole,
Directeur, Informaticien entres autres). Cela sert aussi à enregistrer ses informations
personnelles et à suivre les actions d’un utilisateur
Pour nous faciliter la tâche, ASP.NET implémente déjà ces gestions, il ne nous reste
quasiment plus qu’à les paramétrer.
IV.2.1- La classe Membership
Cette classe permet de gérer les utilisateurs. Elle vous permet entre autres
d’ajouter, supprimer, sélectionner et modifier des utilisateurs. Cette classe se trouve
dans
System.Web.Security.Membership.
Voici les méthodes qu’elle contient :

Méthode Définition
CreateUser Vous permet d’ajouter un utilisateur à la
base de données.
DeleteUser Vous permet de supprimer un utilisateur de
la base de données.
FindUsersByEmail Récupère sous forme de collection tous les
utilisateurs contenant l’adresse passée.
FindUsersByName Récupère sous forme de collection tous les
utilisateurs contenant le nom passé.
GeneratePassword Génère un mot de passe de la taille
spécifiée.
GetAllUsers Récupère tous les utilisateurs sous forme de
collection.
GetNumberOfUsersOnline Récupère le nombre de personnes
connectées.
75
GetUser Récupère l’utilisateur courant. Retourne un
objet MembershipUser.
GetUserNameByEmail Récupère l’utilisateur qui correspond à
l’email passé.
UpdateUser Met à jour l’utilisateur (inscrit les
informations dans la base de données).
ValidateUser Vérifie la validité du login et du mot de
passe.
IV.2.2- La classe Roles
Les rôles permettent de gérer les autorisations comme l’accès à certaines

parties du site. Cette classe se trouve dans System.Web.Security.Roles. Voyons les
méthodes statiques associées à cette classe :
Méthode Description
AddUserToRole Ajoute un utilisateur à un rôle. Il possède plusieurs variantes comme
AddUsersToRole qui ajoute des utilisateurs à un rôle.
CreateRole Créer un rôle.
DeleteRole Supprimer un rôle.
FindUsersInRole Renvoie une collection contenant tous les utilisateurs du rôle spécifié.
GetAllRoles Renvoie une collection contenant tous les rôles existant.

GetRolesForUser Renvoie une collection contenant les rôles auxquels l’utilisateur appartient.
IsUserInRole Renvoie un booléen indiquant si l’utilisateur courant est dans le rôle spécifié.
RemoveUserFromRole Enlève l’utilisateur du rôle spécifié. Il y a pour lui aussi des variantes possibles
comme RemoveUsersFromRoles qui enlève tous les utilisateurs définis du rôle
spécifié
IV.2.3- Outil d’administration Web
76
Avant de faire cette manipulation, il faut que vous prépariez votre site Web. Pour cela
créez des sous dossiers sur lesquels seront appliquées les permissions.
Pour paramétrer les options d’authentification, il existe un outil d’administration

permettant, via une interface graphique, de gérer l’authentification sans toucher à aucun
fichier.
Pour y accéder aller dans le menu Projet puis choisissez Configuration ASP.NET.
Une fois ceci fait vous verrez s’ouvrir une page Web ressemblant à celle ci‐dessous (vous
serez sur l’onglet Accueil). En haut de cette page se trouve des onglets, choisissez l’onglet
Sécurité.
77
78
CONCLUSION
Les nouvelles technologies ont un impact visible dans notre monde actuel. Et cela se
confirme même dans l’éducation nationale. La mise en place d’une application pour le
paiement des frais de scolarité en ligne a permis de mettre à nu toutes les difficultés que
rencontre les établissements dans le paiement et surtout le recueil des fonds. Le service « Frais
Scolaires » donne-t-il un nouveau souffle aux établissements scolaires qui pourront avec peu de
moyens gérer de façon efficiente les paiements scolaires de leurs élèves.
Désormais, à l’aide de son téléphone portable et d’un compte Mobile Money, le parent d’élève
peut effectuer les paiements de tous les frais relatifs à la scolarisation de ses enfants.
Au terme de notre mémoire, nous pouvons dire que la formation de Master en Génie
informatique et Réseaux est très riche. Car elle nous a permis, d’œuvrer comme ingénieur en
Génie Logiciel et de produire des résultats durant ce stage pratique. Il est aussi important de
dire que ce stage nous a beaucoup apporté. Car il nous a permis de comprendre de nouveaux
concepts du vaste mais combien passionnant domaine que représentent le développement
surtout de multiples plateformes, aussi d'augmenter notre expérience en base de données et
enfin de compléter l’excellente base de connaissance acquise à PIGIER Côte d'Ivoire.
79
BIBLIOGRAPHIE ET/OU
WEBOGRAPHIE
Bibliographie
[1] Kablan Taylor Thierry, «Gestion des paramètres de communication: Cas de Moov-CI»,
Mémoire de fin de cycle, Diplôme de Master, NbPages-131, 2014 : PIGIER-CI
Webographie
Microsoft Visual Studio: http://fr.wikipedia.org/wiki/Microsoft_Visual_Studio ; 20 juillet 2015
Microsoft SQL Server: http://fr.wikipedia.org/wiki/Microsoft_SQL_Server ; 1er avril 2014
Eclipse (projet): https://fr.wikipedia.org/wiki/Eclipse_(projet) ; 24 juin 2015
C#: http://fr.wikipedia.org/wiki/C_sharp ; 20 juillet 2015
ASP.NET: http://fr.wikipedia.org/wiki/ASP.NET ; 15 août 2012
DevExpress: https://en.wikipedia.org/wiki/DevExpress ; Septembre 2013
Heroku: https://fr.wikipedia.org/wiki/Heroku ; 31 octobre 2015
Deploying and managing your apps on Heroku: https://devcenter.heroku.com
IX
ANNEXE
Structure des tables (MPD)
Nom de la table : CLASSE

Clé primaire : ID_CLASSE
Clé étrangère :
Support : Disque dur
Longueur d’un enregistrement : 58
Nom champ Type Description Longueur
ID_CLASSE int Identifiant d'une classe 8
LIBELLE_CLASSE varchar Libellé d'une classe 50
Nom de la table : N_ECHEANCE

Clé primaire : ID_ECHEANCE
Clé étrangère : MATRICULE
ID_ECHEANCE Int Identifiant d'une échéance 8
DATE_ECHEANCE datetime Date d'une échéance 15
MONTANT float Montant d'une échéance 8
MONTANT_REGLE float Montant réglé d'une échéance 8
NUM_ECHEANCE int Numéro d'une échéance 8
float Solde avant mise à jour du montant

SOLDEAVTPAIEMENT 8
réglé
MATRICULE varchar Matricule scolaire d'un inscrit 20
X
Nom de la table : N_INSCRIT
Clé primaire : MATRICULE
Clé étrangère : ID_CLASSE, SITE_ID
MATRICULE varchar Matricule scolaire d'un inscrit 20
EXERCICE int Année scolaire d'un inscrit 8
NOM_ELEVE varchar Nom d'un inscrit 100
PRENOMS_ELEVE varchar Prénoms d'un inscrit 100
ID_CLASSE int Identifiant d'une classe 8
SITE_ID int Identifiant de l'établissement 8
Nom de la table : N_PAIEMENT

Clé primaire : IDPAIEMENT
Clé étrangère :
IDPAIEMENT varchar Identifiant du paiement 8
datetime Date et heure d'envoi de
DATE_HEURE_ENVOI 15
la requête a l'operateur
datetime Date et heure de réponse

DATE_HEURE_RECEPTION_TOKEN de la requête de la part de 15
l'operateur
int Etat de transfert d'un

ETAT 8
paiement
int Année scolaire lié au

EXERCICE 8
paiement
XI
float Montant débité par
MONTANT_DEBITE l'opérateur pour un 8
paiement
int Numéro de téléphone

NUMTEL 20
débité
varchar Opérateur lié à la

OPERATEUR 8
transaction
varchar Numéro de session lié à

SESSIONID 255
un paiement
varchar Numéro de la transaction

TOKEN 255
lié au paiement
ID_VIREMENT int Identifiant du virement 8
varchar Matricule scolaire d'un

MATRICULE 20
inscrit
Nom de la table : SITES

Clé primaire : SITE_ID
Clé étrangère :
ADRESSE_SITES varchar Adresse de l'établissement 50
CODE_SITE varchar Code de l'établissement 8
LIBELLE_SITE varchar Libellé de l'établissement 200
RIB varchar RIB de l'établissement 20
int Numéro de téléphone de

TELEPHONE_SITES 50
l'établissement
TYPE_SITE varchar Type d'enseignement de 8
XII
l'établissement
Nom de la table : USERCONFIRM

Clé primaire : ID
Clé étrangère : SITE_ID
ID int Identifiant de l'utilisateur 8
varchar Code d'activation envoyé par email
ACTIVATIONCODE 36
pour confirmation de l'inscription
ADRESSE_SPERSONNE varchar Adresse de l'utilisateur 100
CODE_PERSONNE varchar Matricule de l'utilisateur 50
int Etat de confirmation ou non d'un

CONFIRMA 8
utilisateur
EMAIL varchar Email de l'utilisateur 20
NOM_PERSONNE varchar Nom de l'utilisateur 100
PRENOMS_PERSONNE varchar Prénoms de l'utilisateur 100
TELEPHONE_PERSONNE int Téléphone de l'utilisateur 12
USERNAME varchar Login de l'utilisateur 50
Nom de la table : VIREMENT

Clé primaire : ID_VIREMENT
Clé étrangère :
XIII
ID_VIREMENT int Identifiant du virement 8
CODE_ETAB int Code de l'établissement 8
DATE_EMISSION datetime Date d'émission du virement 15
DATE_CONFIRM datetime Date de réception du virement 15
MONTANT float Montant du virement 8
RIB_ETAB varchar RIB de l'établissement 20
STATUT int Etat du virement 8
USERNAME varchar Utilisateur ayant procédé au virement 50
Extrait de code pour la confirmation d’un enregistrement par Email
protected void ValidateCaptcha(object sender, ServerValidateEventArgs e)

{
Captcha1.ValidateCaptcha(ASPxTxt.Text.Trim());
e.IsValid = Captcha1.UserValidated;
//Verification du captcha saisi
if (e.IsValid)
{
//Verification de la conformité de l'email
if (IsValidEmail(txtEmail.Text.Trim()))
{
//Initialisation d'un code d'activation
string activationCode = Guid.NewGuid().ToString();
//Appelle de la methode d'envoi de mails avec pour parametres le code
d'activation et l'email
SendActivationEmail(activationCode, txtEmail.Text.Trim());
Response.Redirect("RegisterActive.aspx");
}
else
{
LblEmail.Text = "Veuillez SVP saisir une adresse mail valide";
}
}
}
XIV
protected void SendActivationEmail(string activationCode, string email)
{
//Instanciation de la Classe MailMessage pour l'envoi de mail de l'adresse passée en
paramètres.
using (MailMessage mm = new MailMessage("connexions@educativespace.com",
email))
{
//Definition du sujet du mail
mm.Subject = "Activation de compte sur Frais-Scolaires";
//Definition du contenu du mail(Lien d'activation sur la plateforme)
string body = "Bienvenue " + txtLogin.Text.Trim() + ",";
body += " Vous êtes priés de cliquer sur le lien ci-dessous pour l'activation de
votre compte";
body += String.Format(" <a href = '{0}'>Cliquer ici.</a>",
Request.Url.AbsoluteUri.Replace("Register.aspx", "RegisterActive.aspx?
ActivationCode=" + activationCode + "&Login=" + txtLogin.Text.Trim()));
body += " Merci !";
mm.Body = body;
mm.IsBodyHtml = true;
//Configuration pour acceder au serveur d'envoi de mails(Adresse, port à utiliser ...)

SmtpClient smtp = new SmtpClient();
smtp.Host = "smtpout.secureserver.net";
smtp.EnableSsl = false;
//Informations d'identification de l'expediteur du mail
NetworkCredential NetworkCred = new
NetworkCredential("connexions@educativespace.com", "jfr2013**");
smtp.UseDefaultCredentials = true;
smtp.Credentials = NetworkCred;
smtp.Port = 80;
//Envoi du mail
smtp.Send(mm);
}
}
Extrait de code pour l’importation d’un fichier Excel en Base

protected DataTable ImportdatafromExcel(string FileExtension, string FilePath)
{
string conStr = "";
switch (FileExtension)
{
case ".xls": //Pour les fichiers Excels 97-03
XV
conStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + FilePath +
";Extended Properties='Excel 8.0;HDR=Yes'";
break;
case ".xlsx": //Pour les fichiers Excels à partir de office 2007
conStr = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + FilePath +
";Extended Properties='Excel 12.0;HDR=Yes'";
break;
}
//Creation d'une connexion au Classeur Excel par instanciation de la classe oleDb
OleDbConnection connExcel = new OleDbConnection(conStr.Trim());
OleDbCommand cmdExcel = new OleDbCommand();
OleDbDataAdapter oda = new OleDbDataAdapter();
DataTable dt = new DataTable();
cmdExcel.Connection = connExcel;
//Recupere le nom de la première feuille

connExcel.Open();
DataTable dtExcelSchema;
dtExcelSchema = connExcel.GetOleDbSchemaTable(OleDbSchemaGuid.Tables, null);
string SheetName = dtExcelSchema.Rows[0]["TABLE_NAME"].ToString();
connExcel.Close();
//Lecture des données de la première feuille selon le format prédéfini

connExcel.Open();
cmdExcel.CommandText = "SELECT matricule, nom, prenoms, niveau, echeance1, date1,
montant1, echeance2, date2, montant2, echeance3, date3, montant3, echeance4,
date4, montant4, echeance5, date5, montant5, echeance6, date6, montant6 From [" +
SheetName + "]";
oda.SelectCommand = cmdExcel;
//Données de la feuille enregistrée dans un datatable.

oda.Fill(dt);
connExcel.Close();
return dt;
}
XVI
TABLE DES MATIERES
SOMMAIRE..................................................................................................................................................II
DEDICACE...................................................................................................................................................IV
REMERCIEMENTS...................................................................................................................................V
AVANT-PROPOS......................................................................................................................................VI
RESUME....................................................................................................................................................VII
ABSTRACT (SUMMARY).....................................................................................................................VIII
INTRODUCTION...........................................................................................................................................1
PREMIERE PARTIE : CADRE DE REFERENCE..................................................................................................2
I- PRESENTATION DE L’ENTREPRISE.............................................................................................................3
I.1- Historique et présentation................................................................................................................3
I.2- Forme juridique.................................................................................................................................3
I.3- Domaines d’activités.........................................................................................................................4
I.4- Organisation de JFR-SYSTEMS...........................................................................................................4
I.4.1- Direction générale......................................................................................................................4
I.4.2- Secrétariat..................................................................................................................................4
I.4.3- Service comptabilité...................................................................................................................4
I.4.4- Service commercial.....................................................................................................................4
I.4.5- Service technique.......................................................................................................................5
I.4.6- Formateurs-intégrateurs............................................................................................................5
I.4.7- Service Génie logiciel et logistique.............................................................................................5
II- PRESENTATION DU PROJET.....................................................................................................................7
I.1- Contexte (problématique).................................................................................................................7
I.2- Cahier des charges.............................................................................................................................8
I.2.1- Module dédiée à la mise en exploitation et au suivi du bon fonctionnement des opérations de
paiements électroniques.....................................................................................................................8
XVII
I.2.2- Module pour le service USSD.....................................................................................................8
I.2.3- Module API.................................................................................................................................9
I.2.4- Module Virement.......................................................................................................................9
I.3- Objectif..............................................................................................................................................9
III- CHOIX DE LA METHODE D'ANALYSE.......................................................................................................9
III.1-Définition des concepts..................................................................................................................10
III.1.1-L'analyse..................................................................................................................................10
III.1.2-La conception..........................................................................................................................11
III.1.3-L'implémentation....................................................................................................................11
III.2-Classification des méthodes d'analyse et de conception................................................................11
III.2.1-Les méthodes cartésiennes ou fonctionnelles.........................................................................11
III.2.2-Les méthodes systémiques......................................................................................................12
III.2.3-Les méthodes objet.................................................................................................................12
III.2.4-Les méthodes agiles................................................................................................................12
III.3-Choix d'une méthode d'analyse et de conception..........................................................................13
III.3.1-Merise.....................................................................................................................................13
III.3.2-Processus unifié.......................................................................................................................14
III.3.3- Choix de la méthode d’analyse et de conception...................................................................15
DEUXIEME PARTIE : ETUDE PREALABLE.....................................................................................................16
I- ETUDE DE L’EXISTANT.............................................................................................................................17
I.1-Description de l’existant...................................................................................................................17
I.2- Critique de l’existant........................................................................................................................17
I.2.1- Pour les établissements scolaires.............................................................................................17
I.2.1-Pour les parents.........................................................................................................................18
II - PROPOSITION DE SOLUTIONS POSSIBLES.............................................................................................18
II.1- Paiement en ligne...........................................................................................................................18
II.1.1- Description de la solution........................................................................................................18
II.1.2- Inconvénients..........................................................................................................................19
II.2- Paiement mobile............................................................................................................................19
II.2.1- Description de la solution........................................................................................................19
II.2.2- Inconvénients..........................................................................................................................20
XVIII
II.3- Choix d’une solution.......................................................................................................................20
II.3.1- Avantages................................................................................................................................20
II.3.2- Estimation des coûts de mise en œuvre..................................................................................21
TROISIEME PARTIE : ETUDE DETAILLEE......................................................................................................22
I- ETUDE CONCEPTUELLE...........................................................................................................................23
I-1 Modèle conceptuel des données (MCD)..........................................................................................23
I.1.1- Définition..................................................................................................................................23
I.1.2- Concepts de base......................................................................................................................23
I.1.3- Représentation schématique....................................................................................................23
I-2 Modèle conceptuel des traitements (MCT)......................................................................................27
I-2.1- Définition..................................................................................................................................27
I-2.2- Concepts de base.....................................................................................................................27
I-2.3- Représentation schématique d’un MCT...................................................................................29
II- ETUDE FONCTIONNELLE........................................................................................................................38
II.1- Modèle organisationnel des traitements (MOT)............................................................................38
II.1.1- Définition.................................................................................................................................38
II.1.2- Concepts de base.....................................................................................................................38
II.2- Modèle logique de données (MLD)................................................................................................44
III- ETUDE ORGANIQUE..............................................................................................................................45
Modèle physique de données (MPD)....................................................................................................45
QUATRIEME PARTIE : DEPLOIEMENT ET INTEGRATION.............................................................................48
I- ETUDE TECHNIQUE ET PRESENTATION DES PLATEFORMES ATTAQUES.................................................49
I.1-Plateforme USSD..............................................................................................................................49
I.2-Plateforme Web...............................................................................................................................49
II- REALISATION.........................................................................................................................................55
II.1-Présentation des outils et langages utilisés.....................................................................................55
II.1.1-Microsoft Visual Studio 2010....................................................................................................55
II.1.2-Microsoft SQL Server 2008 R2.................................................................................................56
II.1.3- Le langage C#..........................................................................................................................56
II.1.4- Asp.net....................................................................................................................................57
II.1.5-DevExpress...............................................................................................................................57
XIX
II.1.6- Le langage JAVA......................................................................................................................57
II.1.7-Eclipse......................................................................................................................................58
II.2- Présentation des fonctionnalités....................................................................................................58
II.2.1- Liste des fonctionnalités à mettre en œuvre...........................................................................58
II.2.1.1- Module (plateforme) dédiée à la mise en exploitation et au suivi du bon fonctionnement
des opérations de paiements électroniques......................................................................................58
II.2.1.2- Module pour le service USSD................................................................................................58
II.2.1.3- Module (API) pour l’échange d’informations entre la plateforme établissement et le service
USSD..................................................................................................................................................59
II.2.1.4- Module Administrateur pour le virement des montants recueillis pour chaque
établissement....................................................................................................................................59
II.2.2- Description de la mise en œuvre des fonctionnalités..............................................................59
II.2.2.3- Module (API) pour l’échange d’informations entre la plateforme établissement et le service
USSD..................................................................................................................................................61
établissement....................................................................................................................................62
II.2.3- Résultat des fonctionnalités mises en œuvre..........................................................................63
établissement....................................................................................................................................69
III- DEPLOIEMENT DE LA SOLUTION...........................................................................................................69
III.1-Description de l'environnement de déploiement...........................................................................69
III.2- Les procédures de déploiement mise en place..............................................................................69
III.2.1- Application Web.....................................................................................................................69
III.2.2- Service USSD...........................................................................................................................71
IV- SECURITE..............................................................................................................................................72
IV.1- Définition des profils utilisateurs...................................................................................................72
IV.1.1- Le profil Administrateur.........................................................................................................72
XX
IV.1.2- Le profil Administrateur-Ecole................................................................................................73
IV.1.3- Le profil Informaticien............................................................................................................73
IV.1.4- Le profil Directeur..................................................................................................................73
IV.2- Authentification des utilisateurs...................................................................................................73
IV.2.1- La classe Membership............................................................................................................73
IV.2.2- La classe Roles........................................................................................................................74
IV.2.3- Outil d’administration Web....................................................................................................75
CONCLUSION.............................................................................................................................................77
BIBLIOGRAPHIE ET/OU WEBOGRAPHIE.....................................................................................................IX
ANNEXE.......................................................................................................................................................X
TABLE DES MATIERES..............................................................................................................................XVII
XXI

Memoire Master Ok

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire Master Ok

Transféré par

Droits d'auteur :

Formats disponibles

République de Côte d’Ivoire

Union – Discipline - Travail

Présenté par : CREPPY William Ayité

CREPPY William Ayité

II - Proposition de solutions possibles.......................................................................................................18

CREPPY William Ayité

CREPPY William Ayité

Sans être exhaustif, nous aimerions citer :

Toute l’équipe de JFR-SYSTEMS, en particulier le Directeur Général, Monsieur Armel

CREPPY William Ayité

CREPPY William Ayité

Chaque création nécessite différentes étapes prévues par la méthode MERISE, la

CREPPY William Ayité

CREPPY William Ayité

Actuellement, les établissements en général ne disposent pas encore d’outil pour la

Ainsi, la réalisation de cette étude va-t-elle nous amener à répondre à plusieurs

I.1- Historique et présentation

Au cours de ces années de développement, les différentes plates-formes logicielles ont

JFR-SYSTEMS est une société de services en ingénierie informatique basé en Côte

Elle propose une solution complète d’intégration et de maintenance de solutions informatiques

I.2- Forme juridique

I.4- Organisation de JFR-SYSTEMS

I.4.1- Direction générale

I.4.3- Service comptabilité

 Le traitement des factures fournisseurs (réception, imputations, saisies, archivage et

I.4.4- Service commercial

I.4.5- Service technique

Assuré par M. YEO NAMOGOH et un ensemble de techniciens en informatique et en

 La création et l’hébergement de site web ;

I.4.7- Service Génie logiciel et logistique

Il assure l’effectivité du développement des nouvelles fonctionnalités applicatives de la

Il gère le développement et le classement de tous les états statistiques particuliers et

Il a aussi pour rôle d’assurer la rédaction et la diffusion des supports électroniques de

Service Service technique Service administratif et Service génie logiciel et

I.1- Contexte (problématique)

Exemple d'échéancier d’un établissement de la place.

Echéance 01 Echéance 02 Echéance 03

Date Montant Date Montant Date Montant

Frais de scolarité 15 000 15 000 20 000

Cantine 5 000 5 000 5 000

Paiement électronique 1 000 1 000 1 000

 Module (plateforme) dédiée à la mise en exploitation et au suivi du bon fonctionnement

I.2.1- Module dédiée à la mise en exploitation et au suivi du bon

Ce module devra permettre aux établissements d’accéder à un espace où ils pourront :

I.2.2- Module pour le service USSD

Ce module permettra d’échanger avec les opérateurs téléphoniques. Il a pour but de

I.2.3- Module API

III- CHOIX DE LA METHODE D'ANALYSE

Modéliser un système avant sa réalisation permet de mieux comprendre le

Dans le domaine de l'ingénierie du logiciel, le modèle permet de mieux répartir les

III.1-Définition des concepts

Une méthode fait intervenir essentiellement les concepts d'analyse et de conception.

III.1.1.1-La définition des besoins

Il s'agit d'identifier les acteurs et les cas d'utilisation, de structurer le modèle, et

III.1.1.2-La capture des besoins

Elle consiste à collecter des informations (interviews, lecture de documentation) et à la

A ce niveau, il s'agit de restituer les besoins dans un langage compréhensible par le

III.1.1.3-La spécification des besoins

Cette phase consiste à la mise en œuvre des programmes dans un langage de

III.2-Classification des méthodes d'analyse et de conception

Malgré la diversité des méthodes d'analyse et de conception, il est possible de les

III.2.1-Les méthodes cartésiennes ou fonctionnelles

III.2.3-Les méthodes objet