Rapport de Stage Viviane YEO

RÉPUBLIQUE DE CÔTE D’IVOIRE
Union – Discipline – Travail
RAPPORT DE STAGE
Filière : INFORMATIQUE DEVELOPPEUR D’APPLICATION
Thème :
CONCEPTION ET REALISATION
D’UNE APPLICATION DE COLLECTE
Cycle Académique : 2022-2023
Année académique : 2022-2023
MAITRE DE STAGE : PRESENTE PAR :

M HOUINDO LANDRY YEO FOUGPLIN VIVIANE
CONCEPTION ET REALISATION D’UNE APPLICATION DE COLLECTE
TION ET REALISATION D’UNE APPLICATION DE COLLECTE
Sigles et abréviations
UML : Unified Modeling Language
ONG : Organisation Non Gouvernementale
MCD : Modèle Conceptuel de Données
SI : Système d’Information
SAT : Structure d’accès Théorique
MLDR : Modèle Logique de Données Relationnel
MOT : Modèle Organisationnel de Données
MPD : Modèle Physique de données
AGL : Atelier Génie Logiciel
SGBD : Système de gestion de Base de Données
HFSQL : Hyper File Structured Query Language
IDA : Informatique Développeur d’Application
BTS : Brevet d’Etude Supérieur
Page 1 sur 51
SOMMAIRE
Remerciements.......................................................................................................................................................4
Avant-propos..........................................................................................................................................................5
Introduction générale............................................................................................................................................6
PARTIE 1 : PRESENTATION DU CADRE D’ETUDE................................................................................................7
Chapitre I : PRESENTATION DU CADRE DE REFERENCE....................................................................................8
I. Situation géographique....................................................................................................................................8
II. Historique.........................................................................................................................................................8
III. Présentation de l’activité..............................................................................................................................8
IV. Les services et produits d’ONIRIS.................................................................................................................9
Chapitre II : ETUDE DU PROJET..........................................................................................................................11
I. Présentation du projet...................................................................................................................................11
1. Contexte et définition..........................................................................................................................11
2. Problématique du thème....................................................................................................................11
3. Intérêt du projet...................................................................................................................................11
4. Objectif du projet.................................................................................................................................12
II. Etude de l’existant..........................................................................................................................................12
1. Analyse de l’existant.............................................................................................................................12
2. Critique de l’existant............................................................................................................................12
3. Solutions proposées............................................................................................................................13
4. Motivation du choix de MERISE..........................................................................................................13
5. Description du Système d’Information en trois niveaux..................................................................13
PARTIE 2 : ANALYSE DU PROJET........................................................................................................................15
Chapitre III : ETUDE DETAILLE.................................................................................................................................16
I. MISE EN ŒUVRE DU MCD (Modèle Conceptuel de Données)........................................................................16
1. Les règles de gestion...................................................................................................................................16
2. Le dictionnaire des données.......................................................................................................................17
3. La structure d’accès théorique...................................................................................................................22
4. Schema du MCD (Modèle Conceptuel de données)...................................................................................24
II. MISE EN ŒUVRE DU MCT (Modèle Conceptuel de Traitements)...................................................................26
1. Liste des acteurs.........................................................................................................................................27
2. Diagramme des flux....................................................................................................................................28
Page 2 sur 51
3. Graphe D’ordonnance Des Evènements.....................................................................................................28
4. Schéma du MCT (Modèle Conceptuel de Données)...................................................................................30
III. MISE EN ŒUVRE DU MLDR (Modèle Logique de Données Relationnelles)................................................31
IV. MIS EN ŒUVRE DU MOT (Modèle Organisationnel de Traitements).........................................................32
1. Schéma du MOT (Modèle Organisationnel de Données)............................................................................33
V. MISE EN ŒUVRE DU MPD (Modèle Physique de données)............................................................................34
PARTIE 3 : CONCEPTION DU PROJET................................................................................................................39
CHAPITRE IV : RALISATION DU PROJET..................................................................................................................40
I. Outil de développement.............................................................................................................................40
1. Environnement de développement........................................................................................................40
2. Système de gestion de base de données (SGBD)....................................................................................40
3. Environnement matériel cible................................................................................................................40
II. Présentation et description des écrans..........................................................................................................41
Conclusion générale............................................................................................................................................46
BIBLIOGRAPHIE....................................................................................................................................................47
Page 3 sur 51
Remerciements
Je souhaite exprimer ma profonde gratitude à M. DIARRASSOUBA REMI, Directeur Général de

ONIRIS SARL, pour m'avoir offert l'opportunité d'effectuer mon stage au sein de son entreprise
dans des conditions optimales.
Je remercie chaleureusement mon maître de stage, M. HOUINDO, Analyste Programmeur chez

ONIRIS, dont l'expertise, la disponibilité et le soutien constant ont été essentiels à la réussite de
mon stage. Ses conseils avisés et sa confiance en mes capacités m'ont permis de relever les
défis avec assurance et d'atteindre mes objectifs.
Je tiens également à remercier sincèrement tout le personnel de ONIRIS SARL pour leur accueil
chaleureux et les précieux conseils qu'ils m'ont prodigués.
Page 4 sur 51
Avant-propos
PIGIER Côte d'Ivoire est l'un des établissements du réseau international PIGIER, dédié à la
formation et à l'encadrement des étudiants. Ouvert en 1956, l'établissement a connu une
évolution rapide sous la direction dynamique de son directeur à partir de 1972. Cette
croissance a conduit la direction à rechercher de nouveaux locaux, ce qui a abouti à
l'installation de l'école dans l'immeuble « Le Centre », situé sur le boulevard de la République, à
l'avenue Marchand, au Plateau, le quartier des affaires de la ville d'Abidjan.
PIGIER Côte d'Ivoire, l'école où nous avons suivi notre formation, forme des techniciens
supérieurs et des ingénieurs de conception capables de s'adapter aux avancées techniques et
technologiques pour répondre aux attentes des entreprises. Pour y parvenir, elle offre à ses
étudiants une formation théorique et pratique. En fin de cycle, elle organise des stages
professionnels en entreprise pour permettre aux étudiants de parfaire et approfondir leurs
connaissances, facilitant ainsi leur insertion dans le monde professionnel.
Conformément à la plupart des cycles de formation, le Brevet de Technicien Supérieur (BTS)

Industriel, option : Informatique Développeur d'Application (IDA), est un diplôme professionnel
de l'enseignement supérieur. Ce cursus se termine par la réalisation d'un projet de fin de cycle.
Après deux années d'études, comprenant des cours théoriques et des travaux pratiques, il est
demandé aux étudiants en fin de formation de réaliser des stages. Ces stages aboutissent à la
rédaction d'un rapport de stage qui sera soutenu devant un jury composé d'enseignants en
vue de l'obtention du diplôme.
C'est dans ce cadre que nous avons été accueillis par l'entreprise ONIRIS SARL, où nous avons
travaillé pendant trois mois sur le thème suivant : Conception et Réalisation d'une
Application de Collecte. L'évaluation de ce projet se concentre sur une partie des matières de
base de la filière, en mettant l'accent sur la mise en place d'un système d'information (SI)
Page 5 sur 51
Introduction générale
Les institutions de microfinance sont des structures ayant pour mission de fournir des services
bancaires à la frange de la population aux revenus faibles, exclue des services bancaires
classiques. En Côte d'Ivoire, le secteur de la microfinance est structuré autour de deux types
d'institutions : les institutions mutualistes ou coopératives d’épargne et de crédit, et les
institutions non mutualistes (ONG et sociétés anonymes).
L'évolution de la microfinance en Côte d'Ivoire peut être divisée en deux grandes périodes. La
première, allant de 1996 à 2011, a été marquée par une croissance rapide du nombre de
structures. La seconde période a vu une régression du nombre de structures de microfinance
en raison de la mise en place d'une réglementation plus stricte.
Cependant, les collectes effectuées par les petits commerçants auprès des collecteurs de
microfinance rencontrent souvent des problèmes de vols commis par certains collecteurs
malhonnêtes. Partant de ce constat, il nous a été demandé, dans le cadre de ce projet de fin de
cycle, de concevoir une application mobile de gestion de collecte pour sécuriser la gestion des
collectes.
Ce logiciel doit permettre de sécuriser l'activité en gérant :
 Les collectes,
 Les clients,
 Les comptes,
 Les agents collecteurs,
 Les différentes transactions ou mouvements de collecte.
Nous avons nommé cette application "Sigma Collecte". Développée sous WinDev Mobile 25,
elle constitue un outil de gestion efficace et sécurisé pour les institutions de microfinance.
Actuellement, plusieurs solutions de gestion de microfinance existent sur le marché, mais rares
sont celles qui gèrent la collecte de manière spontanée via une application. Sigma Collecte vise
à combler ce vide en offrant une solution simple et flexible aux institutions de microfinance.
Ce projet de fin d'études est structuré en trois parties regroupant quatre chapitres. La première
partie présente la structure d'accueil, la deuxième analyse le projet, et la troisième se concentre
sur la conception de l'application mobile Sigma Collecte.
Page 6 sur 51
Page 7 sur 51
PARTIE 1 : PRESENTATION
DU CADRE D’ETUDE
Page 8 sur 51
Chapitre I : PRESENTATION DU CADRE DE REFERENCE
I. Situation géographique
L’entreprise ONIRIS SARL est une société de services et d’ingénierie informatiques (SSII) située
dans la ville d’Abidjan, plus précisément dans la commune de Treichville Arras 3.
II. Historique
Créé officiellement depuis le 15 juillet 2013, ONIRIS est une société informatique spécialisée
dans l’ingénierie et les services informatiques. Dirigée par une équipe jeune et dynamique, elle
a pour principale vocation d’apporter une innovation technologique aux entreprises. Plusieurs
entreprises bénéficient aujourd’hui de ses prestations, surtout dans le domaine de la
microfinance. Elle réussit à bien s’intégrer dans le monde du multiservice informatique.
III. Présentation de l’activité
On peut regrouper les activités de Oniris en quatre grands domaines :

- Edition de logiciels
- Application web et mobile
- Réseau et système
- Audit et conseil
Page 9 sur 51
DIRECTION GENERALE
Assistante de
Direction
Service Technique Service Comptable Service Commercial
Section
Développement
Section Réseaux et
équipements
Section Assistance
ORGANIGRAMME DE ONIRIS
IV. Les services et produits d’ONIRIS
Pour mener à bien son activité l’entreprise a pris comme gage le respect de sa clientèle. Ainsi,
elle forme et assiste de façon régulière ses clients sur ses logiciels. Notons que l’assistance est
un service à part entier qui peut se faire de manière physique ou à partir d’une application de
contrôle à distance.
ONIRIS a pour principale activité la conception des solutions informatiques appelées

logiciels métiers spécialement conçu pour des besoins bien précis. C’est dans ce sens que
Sigma finances, logiciel de gestion de microfinances a été développé. Il permet de gérer toute
l’activité des microfinances à travers différents modules :
- Gestion des clients

- Gestion des Comptes
Page 10 sur 51
- Gestion des collecteurs
Certains clients ont exprimé leur volonté de n’avoir que le module de gestion de la collecte
journalière, c’est ce qui nous a amené à concevoir une application qui ne gèrera que la collecte,
thème qui a été retenu pour notre projet de fin de cycle.
Page 11 sur 51
Chapitre II : ETUDE DU PROJET
I. Présentation du projet
Le thème soumis à notre étude s’intitule : CONCEPTION ET REALISATION D’UNE

APPLICATION DE COLLECTE.
Contexte et Définition
La conception d’une application de collecte permettra d’alléger la tâche des collecteurs

travaillant pour les institutions de microfinance. Cette application vise à moderniser et sécuriser
le processus de collecte, en facilitant la gestion des transactions et en minimisant les risques
liés à la manipulation de l’argent liquide.
Problématique du Thème
La collecte d’argent auprès des petits commerces par les collecteurs de microfinance nécessite
une gestion importante de ressources humaines. Un bon recrutement est crucial pour atteindre
les objectifs des microfinances. Cependant, il existe des risques associés à cette activité. Si les
collecteurs ne sont pas bien supervisés, ils peuvent effectuer des collectes importantes et
disparaître avec l'argent, causant des pertes significatives pour les institutions.
Les difficultés rencontrées dans le processus de collecte incluent l'ouverture du bordereau du

jour, l'enregistrement des collectes, et l'inscription des clients. Ces étapes posent la question de
l'intérêt de l'informatisation du processus de collecte. En quoi une application mobile pourrait-
elle améliorer l'efficacité et la sécurité de ce processus pour les institutions de microfinance ?
Intérêt du Projet
Les microfinances ont pour objectif de résoudre les problèmes de financement des populations
démunies, souvent confrontées à des déficits financiers. Dans ce contexte, recruter, gérer et
fidéliser des collecteurs compétents et motivés devient une priorité.
L’intérêt de ce projet réside dans la capacité à gérer efficacement les comptes clients et les
collectes journalières. La conception d'un système de collecte automatisé permet de gagner du
Page 12 sur 51
temps, de suivre de près chaque collecte, et de renforcer la sécurité des transactions. Cette
application facilitera également la gestion des ressources humaines et l’amélioration des
performances des collecteurs.
Objectifs du Projet
La conception d’une application de collecte aura pour objectifs :
 De simplifier l’inscription des clients.

 D’attribuer chaque client à un collecteur spécifique.
 De réduire les risques associés à la manipulation de montants élevés.
 De permettre aux clients d’accéder à leur argent sans avoir besoin de se rendre en
agence.
II. Étude de l'Existant

Ce point portera sur la description du système actuel et l’analyse de cet existant.
1. Analyse de l'Existant
La gestion des collectes se fait de manière manuelle, occasionnant de nombreux problèmes
tels que :
 La lenteur dans le traitement des informations.
 Des difficultés dans la gestion des versements ou reversements des sommes collectées,
qui jouent pourtant un rôle très important.
 Le détournement de l’argent des collectes par certains agents collecteurs.
 L’accusation des collecteurs, parfois à tort ou à raison.
Cette situation a commencé à ternir l’image de certaines structures opérant dans ce domaine,
comme en témoignent les plaintes des clients qui ne reçoivent pas leur argent rapidement,
ainsi que les retours du personnel qui trouvent la méthode manuelle très fastidieuse.
2. Critique de l'Existant
Page 13 sur 51
La gestion des collectes, étant purement manuelle, entraîne des traitements d’informations très
lents et souvent désordonnés. De nombreuses erreurs sont fréquemment constatées, et même
des détournements de fonds, parfois minimes, se produisent. Certaines sommes collectées par
des collecteurs chez certains clients ne sont pas déclarées, mais le client continue de faire sa
collecte journalière. Cette situation a causé de nombreux préjudices à certaines structures,
entraînant d'énormes pertes et dettes, et parfois même des répercussions judiciaires.
3. Solutions Proposées
Face à ces problèmes de lenteur, de sécurité, de vol, et à la mise en cause de la crédibilité de
certaines structures, nous proposons d’automatiser la gestion des collectes grâce à une
application mobile. Ce logiciel permettra de gérer :
 Les clients et leurs comptes de versement, permettant de connaître le solde du compte
à tout moment.
 Les reversements journaliers des collectes dans un compte principal.
 Les limites et plafonds de collecte pour chaque collecteur.
 Les différentes opérations réalisées entre collecteurs et clients.
À travers l’analyse de l’existant, il nous a été possible de comprendre le fonctionnement actuel
de la gestion des collectes, d’identifier ses avantages et ses lacunes, et de proposer une
solution pour combler ces insuffisances. Pour cela, nous utiliserons la méthode MERISE pour
une étude détaillée de l’existant.
4. Motivation du Choix de MERISE
Le choix de la méthode MERISE pour ce projet est justifié par plusieurs raisons. Merise et UML
sont deux grands principes de modélisation d'un système d'information, mais ils diffèrent sur
plusieurs aspects :
 Accessibilité
 Précision
 Exploitabilité
Page 14 sur 51
Chaque méthode a ses avantages et ses inconvénients. Si l'on cherche la précision et
l'exploitabilité, UML est préférable. En revanche, pour la clarté et l'accessibilité, MERISE est
recommandée.
Mon application gère des données moins complexes, ce qui rend MERISE plus adaptée, car elle
simplifie la modélisation et l’implémentation.
5. Description du Système d'Information en Trois Niveaux
Les Avantages de MERISE :
 MERISE offre une méthode analytique permettant de distinguer nettement les données
des traitements, tout en permettant une interaction mutuelle entre eux.
 MERISE facilite le dialogue permanent entre la maîtrise d’œuvre (utilisateurs) et la
maîtrise d’ouvrage (informaticiens), évitant ainsi les retours en arrière.
 MERISE exige un formalisme rigoureux.
 MERISE dispose de plusieurs outils de vérification et de validation.
 MERISE n’est dédiée à aucun constructeur.
Les Inconvénients de MERISE :
 La rigueur excessive des formalismes de MERISE peut prolonger les délais de réalisation
et de livraison du projet, augmentant ainsi les coûts.
 MERISE est une méthode spécifiquement française, de plus en plus abandonnée au
profit des standards objets américains comme UML.
Page 15 sur 51
PARTIE 2 : ANALYSE DU
PROJET
Page 16 sur 51
Chapitre III : ETUDE DETAILLE

L'étude détaillée a pour objectif de mettre en évidence les données, les traitements et
l'organisation qui vont régir le système à mettre en place.
I. MISE EN ŒUVRE DU MCD (Modèle Conceptuel de Données)
Le modèle conceptuel des données (MCD) a pour but de représenter de façon structurée les
données qui seront utilisées par le système d'information. Le modèle conceptuel des données
décrit la sémantique c’est à dire le sens attaché à ces données et à leurs rapports et non à
l’utilisation qui peut en être faite. On établit le MCD après avoir recensé et donné un nom à
l’ensemble des données du domaine étudié. Ensuite on étudie les relations existantes entre ces
données (les dépendances fonctionnelles), pour aboutir au MCD.
1. Les règles de gestion
Les concepts de base :
 Entité
Une entité représente un objet du SI (acteur, document, concept, …), ou plus exactement
un ensemble d’objets ayant les mêmes caractéristiques.
 La notion d’occurrence
Une occurrence d’une propriété est une valeur prise par cette propriété ;
Une occurrence d’une entité est un exemplaire de cette entité caractérisée par un
ensemble des valeurs de ses propriétés ;
Une occurrence d’une association est un ensemble formé par une occurrence de chacun
des entités et une occurrence de chacune des éventuelles propriétés de l’association.
IL ne faut pas confondre :
- ENTITE et OCCURRENCE d’entité,
- Ni PROPRIETE et VALEUR de propriété
- Ni ASSOCIATION et OCCURRENCE d’association
Reprenons ces concepts : Une ENTITE est une FAMILLE d’objets ayant les mêmes
caractéristiques, appelées propriétés.
Un MEMBRE de la famille est appelé OCCURRENCE d’entité.
Page 17 sur 51
Une entité représente un ENSEMBLE d’OCCURRENCES.
Une propriété est une information élémentaire qui permet de décrire une entité ou une
association. Une propriété peut prendre une valeur (c’est l’équivalent d’une variable).
De même, une ASSOCIATION est un LIEN entre deux entités ou plus, et une
OCCURRENCE d’association est un lien entre 2 OCCURRENCES d’entités.
_ Un mouvement de compte est généré par une et une seule collecte.

RG1 :
_ Une collecte génère un et un seul mouvement de compte.
_ Un mouvement de compte est exécuté sur un et un seul compte.

RG2 :
_ Sur un compte est exécuté zéro ou plusieurs mouvements de compte.
_ Un compte est possédé par un et un seul client.

RG3 :
_ Un client possède un et un seul compte.
_ Un client appartient à un et un seul collecteur.

RG4 :
_ A un collecteur appartient zéro ou plusieurs clients.
_ Un collecteur ouvre zéro ou plusieurs bordereaux.

RG5 :
_ Un bordereau est ouvert par un et un seul collecteur.
_ Un bordereau est lié à zéro ou plusieurs collectes.

RG6 :
_ Une collecte est liée à un et un seul bordereau.
2. Le dictionnaire des données
Le dictionnaire de données est un tableau dans lequel nous recensons toutes les
informations sur les données traitées dans la base future. Sa présentation exige la mise en
évidence des colonnes ci-dessous :
 La codification
Page 18 sur 51
Il s’agit de donner un code aux différents champs qui rentrent en ligne de compte dans
la base de données.
 La signification
Elle permet de donner les renseignements sur les colonnes codifiées.
 La taille ou longueur
Elle détermine la taille d’une information dans la base de données.
 Le type
Alphabétique (A) Numérique(N) Alphanumérique(AN) Date(D)
 Le tableau du dictionnaire de données
Nature
Type
Code Libellé Longueur Sit Observation
Sig E
A AN N Mvt
ID_Client Identifiant du
AN 20 Sig E ID
client
CL_Matricule Matricule du
AN 50 Sig E
client
CL_Type
Type de Client AN 3 Sit E
CL_Nom
Nom du client A 150 Sig E
CL_Prenom Prénom du
A 150 Sig E
client
CL_Telephone Téléphone du
N 10 Sit E
client
Page 19 sur 51
CL_Mobile Mobile du
N 10 Sig E
client
CL_Email
Email du client AN 100 Sit E
Adresse
CL_Adressepostale
postale du AN 50 Sig E
client
Adresse de
CL_Adressegeo
géolocalisation AN 100 Sit E
du client
CL_Pwd Mot de passe
AN 30 Sit E
du client
Date de
CL_Datenais
naissance du AN 10 Sig E
client
Lieu de
CL_Lieunais
client
CL_Ville
Ville du client AN 60 Sit E
CL_Pays
Pays du client AN 60 Sig E
CL_Fonction Fonction du
AN 50 Sit E
client
REF_ Collecteur Reference du

AN 20 Sig E ID
collecteur
COL_Matricule Matricule du
AN 50 Sig E
collecteur
COL_Type Type du
AN 3 Sit E
collecteur
COL_Nom Nom du
A 150 Sig E
collecteur
COL_Prenom Prenom du A 150 Sig E
collecteur
Page 20 sur 51
COL_Telephone Telephone du
N 10 Sit E
collecteur
COL_Email Email du
AN 100 Sit E
collecteur
Adresse
COL_Adressepostale
postale du AN 50 Mvt E
collecteur
Adresse de
COL_Adressegeo
géolocalisation AN 100 Sit E
du collecteur
COL_Pwd Mot de passe
AN 50 Sit E
du collecteur
Date de
COL_Datenais
naissance du AN 50 Sig E JJ/MM/AA
collecteur
Lieu de
COL_Lieunais
collecteur
COL_Pays Pays du
AN 60 Sig E
collecteur
COL_Fonction Fonction du
AN 60 Sit E
collecteur
CODE_ Collecte Code de la

AN 20 Sig E ID
collecte
Co_Date Date de la
AN 10 Sig E JJ/MM/AA
collecte
Co_Montant Montant de la 24
N Sig E
collecte
Co_Montant_Depôt_ Montant de
Client dépôt au client N 24 Sig E
de la collecte
Co_Montant_Collecteur Montant de la N 24 Sig E
collecte du
Page 21 sur 51
collecteur
Montant des
Co_Montant_Frais N
frais de la 24 Sig E
collecte
NUM_ Compte Numero du

AN 20 Sig E ID
compte
CPT_Solde Solde du
N 24 Sig E
compte
Date de
CPT_Date_Creation
création du AN 10 Sig E
compte
CPT_Saisie Saisie de
AN 25 Sig E
compte
CPT_Suspension Suspension du
AN 25 Sig E
compte
CPT_Dormant Compte
AN 25 Sig E
dormant
CODE_ Code du
Compte_Mouvement compte AN 20 Sig E ID
mouvement
Montant
MV_Montant_Entree
entrée du N 24 Sig E
mouvement
Montant sortie
MV_Montant_Sortie
du N 24 Sig E
mouvement
Solde
MV_Solde_Progressif
progressif du N 24 Sig E
mouvement
MV_Intitulé Intitulé du
AN 150 Sig E
mouvement
ID_ Bordereau Identifiant du AN 20 Sig E ID
Page 22 sur 51
bordereau
BD_Date_Jour Date du jour

du bordereau
BD_Date_Ouverture Date ouverture
du bordereau
Date
BD_Date_fermeture fermeture du AN 10 Sig E JJ/MM/AA
bordereau
Heure
BD_Heure_Ouverture
ouverture du AN 5 Sig E
bordereau
Heure
BD_Heure_fermeture fermeture du AN 5 Sig E
bordereau
Légende
ID : Identifiant Mvt : Mouvement AA : Année N : Numérique
Sit : Situation MM : Mois E : Elémentaire A : Alphabétique
Sig : Signalétique JJ : Jour AN : Alphanumérique
Dictionnaire de données
3. La structure d’accès théorique
La Structure d’Accès Théorique (SAT) est un graphe utilisé dans le cadre de la méthode de
Merise pour modéliser les dépendances fonctionnelles entre les entités dans notre base de
données. Sa représentation exige ces éléments ci-dessous :
 La dépendance fonctionnelle
Elle indique comment une entité est déterminée par une autre.
 La notation
Elle est exprimée sous forme de flèches en fonction de l’entité qui détermine l’autre.
Page 23 sur 51
 La cardinalité
Elle indique combien d’occurrences d’une entité sont associées à une occurrence de
l’autre entité.
Structure d’accès théorique
STRUCTURE D’ACCES THEORIQUE
4. Schéma du MCD (Modèle Conceptuel de données)
Règles de base pour la construction d’un MCD :
Page 24 sur 51
 Règles concernant les propriétés
o Pour qu’il n’y ait pas d’ambigüité possible, une propriété ne peut pas apparaitre
plusieurs fois dans un MCD.
Autrement dit, toutes les propriétés d’un MCD doivent être différentes les unes
des autres.
o Toute propriété doit avoir à un moment donné qu’une seule valeur pour une
occurrence. Par conséquent, un nom de propriété doit toujours être au singulier.
 Règles concernant les entités

o Toute entité doit comporter un identifiant qui permet de distinguer entre elles
toutes les occurrences d’une même entité. L’identifiant est placé en tête des
propriétés et il est souligné.
o Pour chaque occurrence d’une entité, il ne doit y avoir qu’une seule valeur pour
chacune des propriétés à un instant donné. Cette valeur peut changer au cours
du temps, mais à un instant donné, il n’y en a qu’une seule.
 Règles concernant les associations

o L’identifiant d’une association est implicitement formé par la concaténation des
identifiants des entités liées. On ne représente pas cet identifiant au niveau du
MCD. Deux occurrences d’association ne peuvent pas avoir le même identifiant.
Pour une occurrence, l’identifiant ne doit jamais changer de valeur (l’identifiant
est une propriété constante).
o Une association peut avoir des propriétés, mais ce n’est pas obligatoire.
Page 25 sur 51
Schéma du Modèle Conceptuel de Données
Page 26 sur 51
II. MISE EN ŒUVRE DU MCT (Modèle Conceptuel de Traitements)
La modélisation des traitements a pour objectif de faire la représentation dynamique du

Système d’Information (SI) c’est-à-dire de représenter l’enchainement des traitements réalisés.
Cette modélisation s’effectue à deux niveaux :
- Le niveau conceptuel où l’on s’intéresse aux opérations en dehors de toute mise en

œuvre organisationnelle
- Le niveau organisationnel où on se pose la question qui ?, où ?, quand ?
Tout système d'information est composé d’une base d’information et d’un processeur
d’information qui représentent respectivement sa partie statique et dynamique. A l’instar du
Modèle Conceptuel des Données (MCD) qui schématise les données du système d’information,
le Modèle Conceptuel des Traitements (MCT) décrit les traitements et plus précisément toutes
les activités découlant des échanges entre le domaine étudié et le monde extérieur. Il exprime
donc ce que fait le domaine sans se poser le problème de savoir qui le fait, quand et comment.
Les concepts de base :
 Acteurs
Un acteur est une personne morale ou physique capable d’émettre ou de recevoir des
informations.
On distingue deux types d’acteurs :
o Les acteurs internes qui appartiennent au système d’information étudié.
o Les acteurs externes qui n’appartiennent pas au système d’information mais qui
sont l’origine ou la destination de flux d’informations reçus ou émanant du
système d’information.
Dans le Modèle Conceptuel de Traitements, seuls les acteurs externes sont modélisés ;
d’une part parce qu’on ne cherche qu’à formaliser les traitements découlant
d’interactions avec l’environnement et que d’autre part, on ne cherche pas à connaitre
les acteurs internes qui réalisent les traitements en question.
 Evènement
Page 27 sur 51
L’évènement matérialise un fait, qui en se produisant, doit déclencher une réaction du
système.
Parmi les évènements, on distingue les évènements externes et les évènements
internes :
o Les évènements déclencheurs externes sont des évènements émis par un acteur
externe.
o Les évènements internes sont des évènements qui surviennent lorsqu’une
opération se termine. Un évènement interne n’a lieu d’être que si le compte
rendu de la fin d’une opération doit être soit suivi d’une nouvelle réaction du
système d’information, soit de l’émission d’un message vers l’environnement.
 Opération
La réponse à l’arrivée d’un évènement est le déclenchement d’un ensemble de

traitements appelé opération.
Lors de son exécution une opération ne peut pas être interrompue par l’attente d’un
externe. L’exécution d’une opération se ramène à l’exécution d’actions
élémentaires effectuées sur la base d’informations à partir des données portées par le ou les
évènement(s) déclencheur(s).
 Résultat
Un résultat peut être un document, un message externe ou un nouvel état du SI.
 Synchronisation
La synchronisation d’une opération est composée de deux éléments :

o D’une part la liste des évènements (internes ou externes) qui doivent être arrivés
avant de déclencher l’opération.
o D’autre part la règle sous forme d’une proposition logique qui précise de quelle
manière les évènements participent au déclenchement de l’opération.
1. Liste des acteurs
Acteur interne : Collecteur

Acteur externe : Client
Page 28 sur 51
2. Diagramme des flux
E1 ; E5
Client Collecteur
E2 ; E3 ; E4 ; E6 ; E7
Légende :
E1 : Compte d’ouverture demandé.
E2 : Compte crée.
E3 : Client enregistré.
E4 : Client affecté à un collecteur.
E5 : Jour de collecte.
E6 : Client collecté.
E7 : Compte du mouvementé.
3. Graphe D’ordonnance Des Evènements
Page 29 sur 51
Page 30 sur 51
4. Schéma du MCT (Modèle Conceptuel de Données)
SCHEMA DU MCT
Page 31 sur 51
III. MISE EN ŒUVRE DU MLDR (Modèle Logique de Données Relationnelles)
Le modèle logique de données est une représentation hermétique et structurée des données
d’un système d’information, décrivant les entités, les relations entre ces entités ainsi que les
contraintes qui régissent ces relations.
COMPTE_MOUVEMENT (NUM_Compte_Mouvement, MV_Montant_Entree,

MV_Montant_Sortie, MV_Montant_Progressif, MV_Intitilé, #CODE_Collecte, #Num_Compte)
COMPTE (NUM_Compte, CPT_Solde, CPT_Date_Creation, CPT_Saisie, CPT_Suspension,

CPT_Dormant, CPT_Commande_Carte, #ID_Client)
CLIENT (ID_Client, CL_Matricule, CL_Type, CL_Nom, CL_Prenom, CL_Email, CL_Adressepostale,

CL_Adressegeo, CL_Pwd, CL_Datenais, CL_Ville, CL_Pays, CL_Fonction, #ID_Collecteur)
COLLECTEUR (ID_Collecteur, COL_Matricule, COL_Type, COL_Nom, COL_Prenom, COL_Email,

COL_Adressepostale, COL_Adressegeo, COL_Pwd, COL_Datenais, COL_Ville, COL_Pays,
COL_Fonction)
BORDEREAU (ID_Bordereau, BD_Date_Jour, BD_Date_Ouverture, BD_Date_Fermeture,

BD_Heure_Ouverture, BD_Heure_Fermeture, #ID_Collecteur)
COLLECTE (CODE_Collecte, Co_Date, Co_Montant, Co_Montant_Depôt_Client, Co_Collecteur,

Co_Montant_Frais, #ID_Bordereau)
Page 32 sur 51
IV. MIS EN ŒUVRE DU MOT (Modèle Organisationnel de Traitements)
Définitions et formalisme
Le modèle organisationnel de traitements (MOT) s’attache à décrire les propriétés des

traitements non traitées par le modèle conceptuel des données. Il prend en compte les moyens
(les hommes : par qui, où et comment) et l’opportunité de l’automatisation.
Le modèle organisationnel des traitements a pour objectif de :
- Poursuivre le mécanisme de décomposition
- Repartir les traitements entre acteurs
- Définir la nature des traitements.
Les différents concepts manipulés par le MOT sont :
 Poste de travail
Un poste de travail est une cellule d’activité comprenant les moyens humains et matériels
nécessaires à la réalisation de cette activité. Cette cellule exerce son activité dans un lieu
déterminé.
 Le type (nature) du traitement
Le type du traitement définit le degré d’automatisation de ce traitement. Il y a trois (3) types de

traitements :
- Manuel : aucune utilisation de l’informatique,
- Semi-Automatique : succession de tâches manuelles et de traitements informatiques,
- Automatique : Traitement entièrement automatisé.
 La période
La période indique les conditions temporelles d’activité d’une procédure fonctionnelle.
 La procédure fonctionnelle
Une procédure fonctionnelle est un ensemble de traitements exécutés sans interruption par un
même poste de travail utilisant des moyens de traitement d’un type déterminé pendant une
période d’activité déterminée.
Page 33 sur 51
1. Schéma du MOT (Modèle Organisationnel de Données)
Page 34 sur 51
V. MISE EN ŒUVRE DU MPD (Modèle Physique de données)
La description du modèle physique de données (MPD) se fait dans le langage du système de

gestion de base de données correspondant à la solution choisie. Cette description est aussi
influencée par l’environnement technique de développement.
Nom de la table : compte_mouvement Taille : 242 Octets

Clé Primaire : NUM_Compte_Mouvement Nombre Enregistrements : 9.360.000
Support de stockage : Disque dur local Volume : 2.212.031,25 Ko
CODE LIBELLE TYPE LONGUEUR
NUM_Compte_Mouvement Numéro du compte mouvement AN 20

Montant entrée du compte
MV_Montant_Entree N 24
mouvement
MV_Montant_Sortie Montant sortie du compte mouvement N 24
Montant progressif compte N
MV_Montant_Progressif 24
mouvement
MV_Intitulé Intitulé du compte mouvement AN 150
Nom de la table : collecte Taille : 126 Octets

Clé Primaire : CODE_Collecte Nombre Enregistrements : 9.360.000
Support de stockage : Disque dur local Volume : 1.151.718,75 Ko
CODE_Collecte Code de la collecte AN 20

Co_Date Date de la collecte AN 10
Co_Montant Montant de la collecte
N 24
Co_Montant_Dépôt_client Montant du dépôt client de la collecte N 24
Co_Montant_Collecteur Montant du collecteur de la collecte N 24

Co_Montant_Frais Montant des frais de la collecte N 24
Page 35 sur 51
Nom de la table : client Taille : 893 Octets

Clé Primaire : ID_Client Nombre Enregistrements : 15.000
Support de stockage : Disque dur local Volume : 13.081,055 Ko
ID_Client L’identifiant du client AN 20
CL_Matricule Matricule du client AN 50
CL_Type Type de client AN 3
CL_Nom Nom du client A 150
CL_Prenom Prénom du client A 150
CL_Telephone Téléphone du client N 10
CL_Mobile Mobile du client N 10
CL_Email Email du client AN 100
CL_Adressepostale Adresse postale du client AN 50
CL_Adressegeo Adresse de géolocalisation du client AN 30
CL_Pwd Mot de passe du client AN 30
CL_Datenais Date de naissance du client AN 50
CL_Ville Ville du client AN 60
CL_Pays Pays du client AN 50
CL_Fonction Fonction du client AN 50
Page 36 sur 51
Nom de la table : collecteur Taille : 893 Octets

Clé Primaire : ID_Collecteur Nombre Enregistrements : 110
Support de stockage : Disque dur local Volume : 95,928 Ko
ID_Collecteur L’identifiant du collecteur AN 20
COL_Matricule Matricule du collecteur AN 50
COL_Type Type de collecteur AN 3
COL_Nom Nom du collecteur A 150
COL_Prenom Prénom du collecteur A 150
COL_Telephone Téléphone du collecteur N 10
COL_Email Email du collecteur AN 100
COL_Adressepostale Adresse postale du collecteur AN 60
COL_Adressegeo Adresse de géolocalisation du collecteur AN 50
COL_Pwd Mot de passe du collecteur AN 100
COL_Datenais Date de naissance du collecteur AN 30
COL_Ville Ville du collecteur AN 60
COL_Pays Pays du collecteur AN 60
COL_Fonction Fonction du collecteur AN 50
Page 37 sur 51
Nom de la table : bordereau Taille : 60 Octets

Clé Primaire : ID_Bordereau Nombre Enregistrements : 120.120
Support de stockage : Disque dur local Volume : 7.038.281 Ko
ID_Bordereau L’identifiant du bordereau AN 20
BD_Date_Jour Date du jour du bordereau AN 10
BD_Date_Ouverture Date d’ouverture du bordereau AN 10
BD_Date_Fermeture Date de fermeture du bordereau AN 10
BD_Heure_Ouverture Heure d’ouverture du bordereau AN 5
BD_Heure_Fermeture Heure de fermeture du bordereau AN 5
Nom de la table : compte Taille : 129 Octets

Clé Primaire : NUM_Compte Nombre Enregistrements : 15.110
Support de stockage : Disque dur local Volume : 1.903,505 Ko
NUM_Compte Numéro du compte AN 20
CPT_Solde Solde du compte N 24
CPT_Date_Creation Date de création du compte AN 10
CPT_Saisie Saisie du compte AN 25
CPT_Suspension Suspension du compte AN 25
Page 38 sur 51
CPT_Dormant Compte dormant AN 25
Page 39 sur 51
PARTIE 3 : CONCEPTION
DU PROJET
Page 40 sur 51
CHAPITRE IV : RALISATION DU PROJET
Ce chapitre se penche sur les aspects fondamentaux liés à la mise en place de notre système.
I. Outil de développement
Nous avons opté pour WinDev mobile car avec sa facilité d'utilisation, sa capacité à accélérer le
processus de développement grâce à ses générateurs de code automatiques et ses
composants prédéfinis sont un énorme avantage.
1. Environnement de développement
WinDev Mobile 25 est une solution complète de développement d'applications mobiles,

offrant les outils nécessaires pour créer rapidement et efficacement des applications pour les
principales plateformes mobiles.
C’est un Atelier de Génie Logiciel (AGL) développé par PC SOFT, conçu spécifiquement pour la
création rapide et efficace d'applications mobiles multiplateformes. Cette solution logicielle
offre une gamme complète d'outils et de fonctionnalités pour simplifier le processus de
développement d'applications pour les plateformes iOS, Android et Windows Phone.
Que ce soit pour développer des applications pour iOS, Android ou Windows, WinDev Mobile
25 offre une compatibilité native avec les principales plateformes mobiles, ce qui permet aux
développeurs de cibler un large public sans compromettre la qualité ou les performances de
leurs applications.
WinDev mobile à un langage de programmation spécifique à lui-même conçu pour faciliter

l’apprentissage qui est le WLangage, car grâce à ses fonctionnalités de générateur de code il
permet de faciliter le développement.
2. Système de gestion de base de données (SGBD)
En ce qui concerne la gestion de la base de données, notre choix s’est porté sur HFSQL.
En effet, Windev mobile 25 est livré avec un système de gestion de base de données (SGBD)
intégré appelé HyperFileSQL, conçu spécifiquement pour les applications mobiles développées
avec Windev mobile.
Page 41 sur 51
3. Environnement matériel cible
Sigma Collecte, qu’il nous incombe de réaliser est une application de collecte qui a pour but
d’être utilisé par des collecteurs avec des téléphones Android. Nous avons dans le processus
de développement de notre application, opté et fait des tests avec des périphériques Android
ayant des attributs suivants :
Appareils Caractéristique
Smartphone, tablette - Android version 5.1 et plus;

- Stockage : 100 Mo et plus;
- RAM : 1 Go et plus;
II. Présentation et description des écrans
Notre étude débouche ainsi sur la conception d’une application mobile Sigma Collecte. Cette
concrétisation a été réaliser dans le but de créer des interfaces d’inscription du client, de
collecte du client, de connexion et de profil du collecteur. Voici ci-dessous quelques écrans :
▼ La fenêtre d’accueil
Cet écran est le premier que l’on trouve après

ouverture de l’application.
Page 42 sur 51
▼ La fenêtre de connexion ▼ La fenêtre du menu
Page 43 sur 51
Cet écran de connexion est l’interface Cet écran simple et concis permet à
qui permet au collecteur à travers son l’utilisateur d’accéder directement
nom utilisateur et son mot passe aux fonctionnalités majeures de
d’accéder pleinement à l’application. l’application. Ce sont entre autres :
- La collecte ;
- La gestion des clients ;
- La gestion de son profil.
Page 44 sur 51
▼ La fenêtre de sélection du client
Sélection du client
Après le clic du collecteur sur le bouton de collecte, cet écran
intermédiaire s’affiche directement lui imposant de sélectionner le
client qui fait l’objet de la collecte.
Collecte du client
Ensuite, sur cet écran il
renseigne le montant de la
collecte qu’il valide pour
terminer.
Page 45 sur 51
▼ La fenêtre de la liste des clients ▼ La fenêtre de profil du collecteur
Page 46 sur 51
Cet écran affiche la liste de tous les Cet écran constitue un mini
clients que possède le collecteur et tableau de bord permet au
lui permet de voir le solde du client. collecteur de suivre ses
performances. Il le renseigne en
effet, sur son solde et la liste de
ses collectes.
Page 47 sur 51
▼ La fenêtre d’inscription d’un nouveau client ▼ La fenêtre d’options
Cette interface permet au Cet écran s’affiche par-dessus la page de

collecteur de créer des comptes menu lorsqu’on clique sur le bouton en
clients. Il devra renseigner le haut à gauche de la page de menu : c’est
formulaire avec les informations du le volet des options.
client puis prend une photo de ce Il permet de :
dernier pour compléter son profil. - Changer le code PIN ;
Ainsi, le client créer sera alors - Activer l’empreinte digitale ;
ajouté à son portefeuille. - Changer le mode de luminosité du
Après validation le client est créé téléphone en mode sombre
ainsi que son compte. - Un bouton qui lui permet de
quitter l’application.
Page 48 sur 51
Conclusion générale
Ce projet de fin d'études se situe à l'intersection du secteur de la microfinance et de

l'informatique, qui est aujourd'hui un outil incontournable pour une gestion efficace des
entreprises. Ce travail nous a permis, d'une part, d'approfondir nos connaissances en
conception de systèmes d'information et, d'autre part, de nous familiariser avec les notions de
gestion bancaire des microfinances, tout en profitant de l'expérience professionnelle de nos
encadreurs.
Avec l’application Sigma Collecte, la collecte journalière, qui constitue un produit mobilisateur
de fonds, se fera de manière beaucoup plus optimale. Lors de la programmation de cette
application, nous avons porté une grande attention à sa simplicité d'utilisation, avec un
environnement intuitif et des contrôles de saisie, afin de permettre à un agent sans notions en
informatique de s'adapter rapidement.
Cependant, comme tout travail humain, le nôtre peut comporter des imperfections et nous
sommes ouverts aux critiques et suggestions pour l'améliorer.
Notre ambition est de faire évoluer Sigma Collecte en créant une application mobile pour les
clients, leur permettant de suivre régulièrement leurs collectes et de réaliser des retraits sans se
rendre dans une agence de microfinance.
Page 49 sur 51
BIBLIOGRAPHIE
Page 50 sur 51

Rapport de Stage Viviane YEO

Transféré par

Droits d'auteur :

Formats disponibles

Rapport de Stage Viviane YEO

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

Rapport de Stage Viviane YEO

Transféré par

Droits d'auteur :

Formats disponibles

RÉPUBLIQUE DE CÔTE D’IVOIRE

Union – Discipline – Travail

Filière : INFORMATIQUE DEVELOPPEUR D’APPLICATION

Année académique : 2022-2023

MAITRE DE STAGE : PRESENTE PAR :

Je souhaite exprimer ma profonde gratitude à M. DIARRASSOUBA REMI, Directeur Général de

Je remercie chaleureusement mon maître de stage, M. HOUINDO, Analyste Programmeur chez

Conformément à la plupart des cycles de formation, le Brevet de Technicien Supérieur (BTS)

Ce logiciel doit permettre de sécuriser l'activité en gérant :

 Les agents collecteurs,

 Les différentes transactions ou mouvements de collecte.

Chapitre I : PRESENTATION DU CADRE DE REFERENCE

III. Présentation de l’activité

On peut regrouper les activités de Oniris en quatre grands domaines :

Service Technique Service Comptable Service Commercial

IV. Les services et produits d’ONIRIS

ONIRIS a pour principale activité la conception des solutions informatiques appelées

- Gestion des clients

Chapitre II : ETUDE DU PROJET

Le thème soumis à notre étude s’intitule : CONCEPTION ET REALISATION D’UNE

La conception d’une application de collecte permettra d’alléger la tâche des collecteurs

Les difficultés rencontrées dans le processus de collecte incluent l'ouverture du bordereau du

La conception d’une application de collecte aura pour objectifs :

 De simplifier l’inscription des clients.

II. Étude de l'Existant

Chapitre III : ETUDE DETAILLE

I. MISE EN ŒUVRE DU MCD (Modèle Conceptuel de Données)

1. Les règles de gestion

Les concepts de base :

_ Un mouvement de compte est généré par une et une seule collecte.

_ Un mouvement de compte est exécuté sur un et un seul compte.

_ Un compte est possédé par un et un seul client.

_ Un client appartient à un et un seul collecteur.

_ Un collecteur ouvre zéro ou plusieurs bordereaux.

_ Un bordereau est lié à zéro ou plusieurs collectes.

2. Le dictionnaire des données

Elle permet de donner les renseignements sur les colonnes codifiées.

Elle détermine la taille d’une information dans la base de données.

Alphabétique (A) Numérique(N) Alphanumérique(AN) Date(D)

 Le tableau du dictionnaire de données

REF_ Collecteur Reference du

CODE_ Collecte Code de la

NUM_ Compte Numero du

ID_ Bordereau Identifiant du AN 20 Sig E ID

BD_Date_Jour Date du jour

3. La structure d’accès théorique

Structure d’accès théorique

STRUCTURE D’ACCES THEORIQUE

4. Schéma du MCD (Modèle Conceptuel de données)

Règles de base pour la construction d’un MCD :

 Règles concernant les entités

 Règles concernant les associations

Schéma du Modèle Conceptuel de Données

II. MISE EN ŒUVRE DU MCT (Modèle Conceptuel de Traitements)

La modélisation des traitements a pour objectif de faire la représentation dynamique du

- Le niveau conceptuel où l’on s’intéresse aux opérations en dehors de toute mise en

Les concepts de base :

La réponse à l’arrivée d’un évènement est le déclenchement d’un ensemble de

Un résultat peut être un document, un message externe ou un nouvel état du SI.