INTRODUCTION GENERALE

Les banques, par la nature de leurs activités, traitent un volume très important de données sous
différents formats. Cela implique une saisie manuelle de données pour exécuter un processus ou
répondre à un client, ce qui est consommateur de temps et donc très coûteux. Par ailleurs, la saisie
manuelle des données peut générer un grand nombre d’erreurs.

D’autre part, elles sont soumises à un cadre législatif contraignant et en permanente évolution. Afin de
respecter les nouvelles réglementations, les banques doivent effectuer des mises en conformité
récurrentes, souvent lourdes et coûteuses. Ces réglementations visent à protéger le consommateur et à
favoriser la concurrence, elles peuvent déstabiliser les banques, car elles les obligent le plus souvent à
réduire leurs tarifs afin de rester compétitifs.

L’étape la plus visible au niveau opérationnel est la qualité de service, car elle est celle laissant la plus
grande empreinte mémorielle chez les clients, elle est hautement stratégique pour les banques. Pour
les banques, la qualité de service est l’arme absolue pour « durer dans le temps », facteur de la
fidélisation des clients ou de l’abandon au profit d’un concurrent.

Pour devenir encore toujours plus compétitifs, les banques ont tendances à automatiser les tâches
répétitives et récurrentes. L’automatisation apparaît comme une solution viable pour l’ensemble des
acteurs du secteur, car cela permet :
La rationalisation des processus,
La simplification de la mise à l’échelle,
La facilitation de la mise en conformité avec la réglementation

Ainsi, pour s’adapter, la Banque Nationale de Développement Agricole (BNDA) s’est engagée dans une
phase de profonde transformation : canaux de distribution, effectifs, réglementation. C’est dans ce sens
que nous avons effectué une étude au sein de la banque. L’étude que nous avons réalisée a fait sortir
une montée en exigence des emprunteurs, notamment vis-à-vis du caractère moderne et digital de la
relation client.

Vu les difficultés lier dans la gestion des crédits, vu que les banques occupent une place centrale dans
le développement économique et participe grandement à l'amélioration des conditions sociales. Nous
pensons apporter notre contribution dans l'amélioration du système bancaire en mettant en place un
système de gestion des contrats de prêts par l’envoi de SMS.

1
Le choix d’un tel sujet est motivé entre autres par son originalité. Dans nos investigations, nous n'avons
trouvé aucun travail similaire.
Pour cela, il est donc important de réfléchir aux tours de quelques questions suivantes :
Quelle automatisation dans la gestion de la banque en matière de contrôle et suivi de circuit des prêts
aux particuliers pour pallier aux difficultés soulevées ?
L’automatisation des contrats de prêts a-t-elle de l'influence sur la gestion de la banque en matière de
crédit et influence-t-elle les décideurs dans la prise des décisions rationnelles ?

Telles sont les questions auxquelles nous devons chercher à répondre à travers nos investigations en
vue de trouver une solution aux problèmes posés dans la problématique de notre sujet.

Tout au long de l’étude, nous nous focaliserons sur les réponses suivantes :
La conception d'un système d'information serait une solution à quelques problèmes qui se posent dans
une banque et faciliterait les consultations régulières, les suivis des crédits, l'établissement des rapports
d'octroi et remboursement des crédits ;
La mise en place d'un système informatique permettra d'analyser les données à un temps réduit et de
fournir aux décideurs des informations utiles à la gestion de la banque.

Pour atteindre les objectifs nous avons fait appel aux méthodes et techniques ci-dessous :
Méthodes 
L’analyse documentaire qui nous a permis de comprendre le cadre réglementaire du sujet et de le situer
dans le contexte théorique ;
La méthode structuro-fonctionnelle nous a permis de faire connaissance de la structure
organisationnelle de la BNDA et le fonctionnement des ses différents services ;
La méthode Merise qui nous a permis de créer une représentation virtuelle de la réalité ;
La méthode comparative nous a permis d'établir une comparaison entre la gestion actuelle des crédits
et celle informatisée en vue de prendre la décision selon les avantages et inconvénients de chacune.
Techniques 
L’observation directe et participante nous a permis de nous rendre compte des réalités relatives aux flux
des crédits accordés par la BNDA.
L’interview nous a permis de comprendre les difficultés des gestionnaires de crédits et les attentes des
emprunteurs.

2
En effet, pour réaliser ce travail nous envisageons d’utiliser la technologie GSM comme moyen innovant
d’améliorer la gestion des contrats de prêts à la BNDA. Il s’agit donc d’atteindre les objectifs globaux
suivants :
Apporter une qualité de service aux clients
Désengorgement et résorption des files d’attente devant les points de services
Faire le reporting à l’intention des responsables métiers et des décideurs.

Compte tenu de la complexité des problèmes liés à la gestion des prêts bancaires, nous préférerons
nous limiter uniquement à l'étude des crédits accordés par la BNDA aux clients particuliers.

Outre que l'introduction et la conclusion générales, le document sera organisé en quatre chapitres.
Dans le premier chapitre nous verrons la présentation de la BNDA, l’aperçu général sur le système Gsm
couvre le deuxième, Le troisième chapitre s’articule sur la conception de notre système et en fin le
dernier chapitre qui est le quatrième porte sur la réalisation du système.

3
 CHAPITRE I :
PRESENTATION DE LA BNDA

4
 CHAPITRE II :
APERÇU GENERAL SUR LE SYSTEME
GSM

5
 CHAPITRE III :
CONCEPTION DU SYSTEME

I. ANALYSE PREALABLE 

6
1. Analyse de l’existant 

Les prêts aux particuliers sont des concours à court, moyen ou long terme accordés par la BNDA à ses
clients salariés et pensionnés sous certaines conditions.
Peuvent avoir accès à ces prêts les clients ayant au minimum un (01) mois de domiciliation effective du
salaire ou de la pension à la BNDA et, bien sûr, à jour de leurs engagements vis-à-vis de la Banque.
Le montant du prêt octroyé est fonction de la durée de remboursement et de la quotité cessible du
salaire calculée sur la base du salaire mensuel jusqu’à concurrence de :

 1/4 pour les salaires compris entre 20 960 FCFA et 62 880 FCFA,
 1/3 pour les salaires de 62 881 FCFA à 125 760 FCFA,
 1/2 pour les salaires de 125 761 FCFA à 251 520 FCFA,
 3/4 pour les salaires supérieurs à 251 520 FCFA.
La durée de remboursement est déterminée en fonction de l’objet du prêt. Toutefois, elle ne peut
excéder la durée du contrat de travail de l’emprunteur. La BNDA accorde trois natures de prêt :

 le prêt à court terme dont la durée n’excède pas 24 mois ;

 le prêt à moyen terme dont la durée est comprise entre 25 et 96 mois inclus ;
 le prêt à long terme (ou prêt immobilier) dont la durée est supérieure à 96 mois.
Le mode de remboursement des prêts aux particuliers est mensuel. Le remboursement commence
immédiatement à compter du premier virement de salaire suivant le déblocage du prêt. Le
remboursement du capital est croissant ; mais les échéances en capital + intérêts (y compris TAF) sont
constantes.
Les échéances sont constantes et le taux varie en fonction de la nature du prêt conformément à la grille
des commissions en vigueur. Actuellement, il se présente comme suit :

 Prêt à court terme : 10% + TAF (17%)

 Prêt à moyen terme : 9% + TAF (17%)
 Prêt à long terme (ou prêt immobilier) : 8% + TAF (17%)
Un dossier de prêt aux particuliers doit comprendre les éléments ci-après :

 une demande de prêt comportant le numéro de compte du client, l’objet du financement et le

montant sollicité ;
 Une attestation de service ou de présence au corps pour les militaires ;
 Un relevé de compte du client faisant apparaître la domiciliation effective du salaire ;

7
  L’acte de domiciliation effective du salaire revêtu du cachet et de la signature du service
employeur ;
 Les trois derniers bulletins de salaire ;
 Une copie du contrat de travail pour les conventionnaires ;
La BNDA a décidé d’assurer elle-même la couverture du risque décès de sa clientèle par la création
d’un fonds d’Assistance pour les décès qui sera alimenté par des primes à la charge de la clientèle.
Le taux des primes est déterminé en fonction de l’âge de l’emprunteur à la date du remboursement de
la dernière échéance. Ce taux est de 1,25% du montant du prêt pour les personnes ayant au plus 40
ans. Il est de 1,75% pour celles dont l’âge est compris entre 40 et 50 ans et 2% pour celles âgées de
plus de 50 ans.
En fonction du terme du prêt, le fonds sera alimenté par des primes dont le montant sera calculé « ad
valorem » ou « prorata temporis ».
Pour les prêts à court terme d’une durée inférieure ou égale à 12 mois la prime est déterminée par une
commission unique calculée sur le montant. Cette commission est dite ad valorem.
Pour les prêts à court terme d’une durée supérieure à 12 mois, la prime est constituée par une
commission ad valorem la première année. Pour les autres années restant à courir, elle est calculée
prorata temporis, c’est-à-dire en fonction de la durée restant à courir, sur le montant du capital restant
dû.
Pour les prêts à moyen ou long terme, la prime est incorporée au montant des échéances.
Tous les prêts accordés aux particuliers sont à échéances constantes et à intérêts décroissantes.
La procédure d’octroi des prêts aux particuliers est la suivante :
Le client adresse à la banque une demande de prêt accompagnée des pièces ci-dessus énumérées. Le
gestionnaire du client analyse le dossier, élabore un contrat de prêt qu’il soumet à la signature du chef
de représentation puis du client. Le gestionnaire saisit ensuite l’autorisation dans le système
d’information de la banque. Après validation de l’autorisation par le chef de représentation, le
gestionnaire enregistre la mise à disposition et débloque le montant au crédit du compte de
l’emprunteur.

8
2. Le diagramme des Flux

EMPRUNTEUR

CHEF DE
6 7 REPRESENTATION

2
4

GESTIONNAIRE
5

9
3. Critique de l’existant

Elle découle de l’étude de l’existant préalablement menée et a pour but de faire apparaître les
différentes insuffisances du système d’information existant.
A la BNDA, les contrats de prêts sont saisis à l’aide de Microsoft Excel ou de Microsoft
Word. Cela entraîne les insuffisances suivantes :

 Les erreurs de saisie et de calcul sont très courantes ;

 Les contrats ne sont pas uniformes d’une agence à une autre ;
 Les contrats ne sont pas toujours conformes aux procédures de crédit de la BNDA ;
 Les fiches de domiciliation sont difficilement remplies par les clients ;
 Les conseillers n’ont pas les statistiques de leur production ;
 Les traitements sont très lents.

4. Ebauche de solutions

Afin de remédier aux différentes insuffisances recensées, nous proposons de concevoir une
application de gestion des prêts aux particuliers. Cette application va permettre :

 de répertorier tous les clients particuliers ;

 l’enregistrement de toutes les demandes de prêts des particuliers ;

 simuler le montant pouvant être octroyé ;

 éditer la fiche de domiciliation du salaire ;
 éditer la fiche de domiciliation de la pension ;
 éditer le contrat de prêt ;
 éditer le tableau d’amortissement d’un prêt ;
 produire différentes statistiques.

Principe :

Il est question de concevoir un système automatisé de gestion sous forme de processus de

travail. Cela va nécessiter la gestion des profils des utilisateurs et des autorisations par groupe
dans le souci de sécuriser l’accès aux données.
L’application va mettre un accent particulier sur l’édition des contrats et de la fiche de
domiciliation. Les statistiques seront fournies immédiatement.

10
II. ELABORATION DES MODELES DE DONNEES

1. Dictionnaire des données 

Le dictionnaire des données est un document qui contient toutes les informations nécessaires
pour l’automatisation.

11
 Codification D ésignation en claire N ature Type Longueur Observation
ag_id Identifiant de l’agence E N Automatique
ag_num code de l’agence E A 3 Obligatoire
ag_nom Nom de l’agence E A 15 Obligatoire
ag_chef Nom/ prénom chef agence E A 50 Obligatoire
gest_id Identifiant du gestion E N Automatique
gest_num Code du gestionnaire E AN 3 Obligatoire
gest_nom Nom du gestionnaire E A 15 Obligatoire
gest_prenom prénom du gestionnaire E AN 3 Obligatoire
clt_id Identifiant du client E N Automatique
clt_num Numéro du client E AN 7 Chiffres
clt_nom Nom du client E A 20 Obligatoire
clt_prenom Prénom du client E A 40 Obligatoire
clt_nais Date de naissance du client E Date 8 jj/ mm/ aaaa
clt_adr Adresse du client E A 50 Obligatoire
clt_tel Téléphone du client E AN 8 Obligatoire
clt_mat Matricule du client E AN 12 Obligatoire
clt_prof profession du client E A 20 Obligatoire
clt_type type de client E B 1 salarié/ retraité
cpt_id Identifiant du compte E N Automatique
cpt_num Numéro de compte E AN 12 Chiffres
cpt_lib Intitulé du compte E A 50 Obligatoire
dos_id Identifiant du dossier E N Automatique
dos_num Numéro du dossier E AN 7 Séquence
dos_objet O bjet du financement E A 100 Obligatoire
dos_mt Montant du prêt E N Monétaire
dos_date Date d’instruction E D 8 jj/ mm/ aaaa
dos_debut Date début remboursement E D 8 jj/ mm/ aaaa
dos_dure Durée du prêt E N 2 Entier court
dos_echeance Montant de l’échéance C N Monétaire
dos_taux Taux d’intérêt E N Pourcentage
dos_frais Commission de dossier C N Monétaire
emp_id Identifiant de l'employeur E N Automatique
emp_num Nom court de l'employeur E A 15 Obligatoire
emp_nom Nom complet de l'employeur E A 100 Obligatoire
loc_id Identifiant de la localité E N Automatique
loc_nom Désignation de la localité E A 50 Obligatoire

E= Elémentaire N= Numérique AN = Alphanumérique

C= Calculée A= Alphabétique

2. Règles de gestion 

Elles décrivent les règles d'organisation de la base de données à construire. 

12
R1. La BNDA compte plusieurs représentations. Chaque représentation dirigée par un chef
porte un code unique de trois chiffres.
R2. Dans chaque représentation, il y a au moins un gestionnaire. Cependant, un gestionnaire
est affecté dans une seule représentation et gère plusieurs clients de cette représentation. Tous
les gestionnaires sont identifiés de façon unique par un code de trois chiffres ;
R3. Un client ne peut être géré que par un seul gestionnaire ;
R4. Chaque client, identifié par un numéro unique, peut ouvrir plusieurs comptes ;
R5. Un client peut cumuler plusieurs prêts de nature différente.
R6. Chaque prêt est unique. Il est principalement caractérisé par un numéro, un montant, un
objet, un début, une durée, le montant de l’échéance ;
R7. Le montant de l’échéance comprend le capital et les intérêts. Il est calculé à partir du
montant du prêt, de la durée du prêt, du taux d’intérêt, de la taxe sur les activités financières et
dans le cas des prêts à moyen et long terme, du fonds d’assistance décès.

13
3. Dépendances Fonctionnelles 

Un attribut B dépend fonctionnellement d’un autre attribut A si, étant donné une valeur de A,
il lui correspond une unique valeur de B (quel que soit l'extension).

Les règles de gestion ci-dessus citées nous permettent d’obtenir les dépendances
fonctionnelles ci-après à partir du dictionnaire des données :

ag_id ag_num gest_id gest_num

ag_nom gest_nom
ag_chef gest_prenom
ag_id

cpt_id cpt_num clt_id clt_num

cpt_lib clt_nom
clt_id clt_prenom
clt_nais
emp_id emp_num clt_adr
emp_nom clt_tel
clt_mat
loc_id loc_nom clt_prof
clt_type
dos_id dos_num loc_id
dos_objet emp_id
dos_mt
dos_date
dos_debut
dos_dure
dos_echeance
dos_taux
dos_frais
cpt_id

14
4. Modèle Conceptuel des Données 

Le Modèle Conceptuel de Données (MCD) est une représentation statique du système

d’information de l’entreprise. Il a pour objectif de constituer une représentation claire et
cohérente des données manipulées dans l’entreprise en décrivant leur sémantique (le sens
attaché à ces données) et les rapports qui existent entre elles.
Les dépendances fonctionnelles précédemment élaborées conduisent au Modèle Conceptuel
de Données suivant :

agence 1,n contenir 1,1 gestionnaire 1,n gerer 1,1 client

ag_id gest_id clt_id
ag_num gest_num clt_num
ag_nom gest_nom clt_nom
ag_chef gest_prenom clt_prenom
clt_nais
clt_adr
dossier 1,1 debloquer 1,n compte 1,1 ouvrir 1,n clt_tel
dos_id cpt_id clt_mat
dos_num cpt_num 1,1 clt_prof
dos_objet cpt_lib clt_type
dos_mt 1,1
travailler
dos_date habiter
dos_debut
dos_dure employeur 1,n 1,n
dos_echeance emp_id localite
dos_taux emp_num loc_id
dos_frais emp_nom loc_nom

15
5. Modèle Logique des Données :

Il permet de modéliser la structure selon laquelle les données seront stockées dans la future
base de données.
Nous obtiendrons le modèle logique de données ci-après en respectant les règles suivantes :

- Toute entité devient une relation ayant pour clé primaire son identifiant. Chaque propriété
se transforme en attribut.
- Toute association hiérarchique (de type [1, n]) se traduit par une clé étrangère. La clé
primaire correspondant à l'entité père (côté n) migre comme clé étrangère dans la relation
correspondant à l'entité fils (côté 1).

agence (ag_id, ag_num, ag_nom, ag_chef)

gestionnaire (gest_id, gest_num, gest_nom, gest_prenom, #ag_id)

employeur (emp_id, emp_num, emp_nom)

localite (loc_id, loc_nom)

client (clt_id, clt_num, clt_nom, clt_prenom, clt_nais, clt_adr, clt_tel, clt_mat, clt_prof,
clt_type, #loc_id, #emp_id)

compte (cpt_id, cpt_num, cpt_lib, #clt_id)

dossier (dos_id, dos_num, dos_objet, dos_mt, dos_date, dos_debut, dos_dure, dos_taux,

dos_echeance, dos_frais, #cpt_id)

Les clés primaires sont soulignées et les clés étrangères précédées du sign dièse (#).

16
6. Modèle Physique des données (MPD)

Cette étape consiste à traduire le modèle logique des données dans le SGBD dans le langage
de définition de données du SQL.

a. Table agence

NOM : agence Description : gestion des agences

Automatisation de la gestion Organisation : SI Clé Primaire : ag_id
des prêts aux particuliers Type. : Permanent
Clés secondaires : ag_num
Nom Champ Type Largeur Observation
ag_id entier 4 octets serial
ag_num chaine 3 caractères chiffres
ag_nom chaine 15 caractères Tout en majuscule

b. Table gestionnaire

NOM : gestionnaire Description : gestion des

gestionnaires
Automatisation de la gestion
Organisation : SI Clé Primaire : gest_id
des prêts aux particuliers
Type. : Permanent
Clés secondaires : gest_num
Clés étrangères : ag_id
Nom Champ Type Largeur Observation
gest_id entier 4 octets serial
gest_num chaine 3 caractères chiffres
gest_nom Chaine 15 caractères Tout en majuscule
gest_prenom Chaine 30 caractères 1ère lettre en majuscule
ag_id entier 4 octets Intégrité référentielle

c. Table employeur

NOM : employeur Description : gestion des employeurs

Automatisation de la gestion Organisation : SI Clé Primaire : emp_id
des prêts aux particuliers Type. : Permanent
Clés secondaires : emp_num
Nom Champ Type Largeur Observation
emp_id entier 4 octets serial
emp_num chaine 15 caractères Tout en majuscule
emp_nom chaine 100 caractères 1ère lettre en majuscule

17
d. Table localite

NOM : client Description : gestion des localites

Automatisation de la gestion Organisation : SI Clé Primaire : loc_id
des prêts aux particuliers Type. : Permanent
Clés secondaires :
Nom Champ Type Largeur Observation
loc_id Entier 4 octets serial
loc_nom Chaine 50 caractères 1ère lettre en majuscule

e. Table client

NOM : client Description : gestion des clients

Automatisation de la gestion Organisation : SI Clé Primaire : clt_id
des prêts aux particuliers Type. : Permanent
Clés secondaires : clt_num
Clés étrangères : gest_id, emp_id, loc_id
Nom Champ Type Largeur Observation
clt_id Entier 4 octets serial
clt_num Chaine 7 caractères chiffres
clt_nom Chaine 20 caractères Tout en majuscule
clt_prenom Chaine 40 caractères 1ère lettre en majuscule
Clt_nais Date 8 octets JJ/MM/AAAA
Clt_adr Chaine 80 caractères 1ère lettre en majuscule
Clt_tel Chaine 25 caractères 99 99 99 99 / 99 99 99 99
Clt_mat Chaine 20 caractères Tout en majuscule
Clt_prof Chaine 50 caractères 1ère lettre en majuscule
Clt_type Booléen Salarié (1) / Retraité (0)
gest_id entier 4 octets Intégrité référentielle
emp_id entier 4 octets Intégrité référentielle
loc_id entier 4 octets Intégrité référentielle

f. Table compte

NOM : client Description : gestion des comptes

Automatisation de la gestion Organisation : SI Clé Primaire : cpt_id
des prêts aux particuliers Type. : Permanent
Clés secondaires : cpt_num
Clés étrangères : clt_id
Nom Champ Type Largeur Observation
cpt_id Entier 4 octets serial
cpt_num Chaine 12 caractères chiffres
cpt_lib Chaine 50 caractères 1ère lettre en majuscule
clt_id Entier 4 octets Intégrité référentielle

g. Table dossier

18
 NOM : dossier Description : gestion des dossiers
Automatisation de la gestion Organisation : SI Clé Primaire : dos_id
des prêts aux particuliers Type. : Permanent
Clés secondaires : dos_num
Clés étrangères : clt_id
Nom Champ Type Largeur Observation
dos_id Entier 8 octets bigserial
dos_num Chaine 7 caractères chiffres
dos_objet Chaine 50 caractères 1ère lettre en majuscule
dos_mt Entier 4 octets
dos_date Date 8 octets JJ/MM/AAAA
dos_debut Date 8 octets JJ/MM/AAAA
dos_dure Entier 2 octets
court
dos_taux Réel 2 chiffres après la décimale
dos_echeance Entier 4 octets
dos_frais Entier 4 octets
cpt_id entier 4 octets Intégrité référentielle

19
III. ELABORATION DU MODELE DE TRAITEMENT

1. Modèle Conceptuel de Traitement (MCT)

20
Le Modèle Conceptuel de Traitement permet donc de représenter de façon schématique
l'activité du système d'information.

21
 Poste de
Période Procédure fonctionnelle Nature
travail

Arrivée demande
Réception demande

Imputation demande Chef

Manuel
Toujours d'agence

Demande imputée

Ins truction dos s ier

Toujours
Imputation demande

Sémi - automatique
Conseiller clientèle
Dossier analysé

S oumis s ion dos s ier

Toujours

Dossier soumis
Soumission

S ignature contrat
dossier

Chef
NOK OK Manuel
d'agence
Dossier rejeté Contrat signé
Dès réception du Après signature
du contrat

Conseiller

Remis e contrat
clientèle

Toujours Manuel

Contrat remis

Approbation contrat
contrat

Client

NOK OK Manuel

Dossier annulé Contrat approuvé

approbation du

Automatique
Conseiller

Déblocage prêt
contrat

clientèle
Après

Toujours

Prêt débloqué

22
23
 CHAPITRE IV :
REALISATION DU SYSTEME
I. INTRODUCTION

L'objectif de ce chapitre est d'aboutir à un produit final, exploitable par les utilisateurs. En
premier lieu, nous présenterons le modèle d'implémentation, qui illustre l'architecture
physique pour la construction de notre application. Ensuite, nous spécifierons les outils,
langages et techniques utilisés et nous finirons par présenter les scénarios les plus généraux de
notre application illustrés par des captures d'écrans.
II. PRESENTATION 

La solution que nous allons développer est une application de gestion des prêts aux
particuliers.

Conçu suivant l'architecture client-serveur, cette application trouve sa pertinence au fait

qu'elle traite des données de façon centralisée et accessibles par n'importe quel poste connecté
au réseau et ayant les droits d'accès requis.

Elle dispose d'un très grand nombre de fonctionnalités et permet une gestion multi site et
Multi-utilisateur des différentes modules développés. Les traitements effectués par cette
application permettent de fournir des informations fiables. C’est un excellent outil d'aide à
l'optimisation de la gestion des prêts aux particuliers.
III. OUTILS ET TECHNIQUES DE DEVELOPPEMENT

L’application est bâtie sur une architecture client/serveur dotée d’API SMS. La réalisation
d’une telle application nécessite forcément un certain nombre d’outils dont un système de
gestion de bases de données, un langage de programmation, la connexion internet pour
l’implémentation des API (Application Programming Interface).

1. Système de Gestion de Bases de Données 

Il existe sur le marché de nombreux systèmes de gestion de bases de données très

performants. Notre choix s’est porté sur PostgreSQL qui est un outil robuste et puissant, aux
fonctionnalités riches et avancées, capable de manipuler en toute fiabilité de gros volumes de
données, même dans des situations critiques.

PostgreSQL intègre le langage PL/SQL qui permet de manipuler des opérations complexes
sur les données en transmettant un bloc de programmation au lieu d'envoyer une requête SQL.
Les traitements sont directement réalisés par le système de gestion de bases de données. Cela
a pour effet notamment de réduire le nombre d'échanges à travers le réseau et donc
d'optimiser les performances des applications.

D'autre part le langage PL/SQL permet de faire appel à des procédures externes, c'est à-dire
des procédures écrites dans un autre langage. Il offre également un moyen d'identifier et de
traiter les éventuelles erreurs à l'aide du mécanisme des exceptions. En cas d'erreur, celle-ci
est automatiquement transmise à un bloc EXCEPTION permettant de la traiter.

PostgreSQL fonctionne sur les principaux systèmes d'exploitation : Linux, UNIX, BSD,
MacOs, Solaris, Windows et supporte de nombreux langages de programmation.

Open-source et gratuit, il est développé par une communauté mondiale regroupant des milliers

de développeurs et plusieurs dizaines d'entreprises. Il est téléchargeable sur le site
https://www.postgresql.org.

2. Langage de programmation 

Tout comme les systèmes de gestion de base de données, il existe également sur le marché de
nombreux langages de programmation. Nous avons choisi l’outil de développement intégré
WinDev en raison de sa simplicité. C’est un langage de programmation très complet édité par
la société française PC SOFT et conçu pour développer des applications, principalement
orientées données pour Windows et également pour Linux, .NET et Java. Il fonctionne avec
de nombreux systèmes de gestion de base de données.
3. Application Programming Interface (API) SMS 

API est un acronyme pour Application Programming Interface, que l'on traduit en français par
Interface de Programmation Applicative. Elle peut être résumée à une solution informatique
qui permet à des applications de communiquer entre elles et de s'échanger mutuellement des
services via un langage de programmation. Elle permet aux développeurs de pouvoir utiliser
un programme sans avoir à se soucier du fonctionnement complexe d'une application. 33

Nous allons utiliser l'API SMS d'Orange qui est un service REST récent permettant d'envoyer
et de recevoir des SMS depuis une application tierce. L’implémentation dans l’application de
l’API SMS d’orange, nécessite le passage par quelques étapes :

3.1. Enregistrement de l’application :

Afin de pouvoir envoyer des requêtes sur les API d'Orange, l’enregistrement de l’application
est obligatoire auprès de la plateforme technique d’orange https://developer.orange.com.
Ensuite, on obtient :

 un « Client Id » : un identifiant unique fournit par la plateforme Orange

 Un « client secret » : utilisé pour signer/crypter la requête et qui doit être partagé par le
client et le serveur.
 Une « Autorisation Basic » : la concaténation du client id et du secret id.

3.2 Génération du Token (jeton) d’accès :

Un token d’accès est une chaîne opaque qui identifie un utilisateur, une application ou une
page. Il contient notamment sa date d’expiration et le nom de l’application qui l’a généré.
Plusieurs méthodes ou outils permettent d’obtenir des tokens d’accès (Postman, RestClient,
CURL).

Dans notre cas, nous allons utiliser le CURL sous Debian. Pour cette action, nous allons
utiliser la méthode POST sur le endpoint /oauth/v2/token :

curl -X POST \
-H "Authorization: Basic
Wnc0MW9BUllLVExvMXRHME3c3SzQ4VW86Zmp4QXR6aHJUaGcxREtaYw" \
-d "grant_type=client_credentials" \
https://api.orange.com/oauth/v2/token
Si la méthode POST retourne un succès, le corps de la réponse au format JSON, doit être
similaire à :

HTTP/1.1 200 OK
Content-Type: application/json
{
"token_type": "Bearer",
"access_token": "i6m2iIcY0SodWSeTrecVaL3ojAXXrH",
"expires_in": "7776000"
}

A noter que 7776000 secondes équivaut à 90 jours.

3.3 Envoi de SMS :

Afin d'envoyer des SMS depuis l’API, il faut d'abord acheter un bundle de SMS depuis le
bouton « Configure » sur la plateforme technique https://developer.orange.com. Ensuite, nous
allons saisir dans notre application, les lignes de codes ci-après pour qu’elle puisse envoyer
des SMS aux clients. Pour ceci, nous utiliserons le token que nous avons généré dans l'en-tête
« Autorisation » et accéderons à l’endpoint
«/smsmessaging/v1/outbound/{senderAddress}/requests », comme ceci :

curl -X POST -H "Authorization: Bearer i6m2iIcY0SodWSeTrecVaL3ojAXXrH "

-H "Content-Type: application/json"
-d '{"outboundSMSMessageRequest":{"address": "tel:+223abcdefgh","senderAddress":"tel:
+22300000000","outboundSMSTextMessage":{"message": "Votre prêt est OK !"}}}'
"https://api.orange.com/smsmessaging/v1/outbound/tel%3A%2B22300000000/requests"

La valeur du paramètre "SenderAddress" dans le endpoint {senderAddress} et dans le body

JSON doit être identique.

Il faut noter que, sur le téléphone du destinataire, sera affiché un expéditeur qui sera généré
par l’API SMS. Cet expéditeur est lié au compte de l’application sur la plateforme technique
d’orange https://developer.orange.com.

Cette requête retourne des données en en-tête et dans le corps de la réponse au format JSON
comme quoi le SMS a bien été expédié ; sinon vous obtiendrez un message d'erreur avec une
description de l'erreur dans le JSON.
 IV. PRESENTATION DE L’APPLICATION

Les interfaces graphiques sont conçues simplement dans l'optique de permettre une utilisation
facile de l'application.

Pour la réalisation de l’application, nous avons tenu compte des équipements et infrastructures
existants à la BNDA. La BNDA dispose déjà de plusieurs serveurs (Linux, Windows, AS
400) et le serveur de bases données PostgreSQL est déjà présent. En plus, tous les postes de
travail sont en réseau.

1. Installation :

Il s’agit donc de créer et installer la base de données sur PostgreSQL et de procéder à

l’installation de l’application sur les postes clients en sélection des paramètres par défaut
comme ci-dessous illustré.
2. Lancement de l’application 

Le lancement de l’application se fait à partir du menu démarrer ou à partir de son raccourci sur le
bureau.

2.1 Fenêtre d’authentification :

C'est l'interface commune pour tous les utilisateurs. Pour accéder à l'application, l’utilisateur doit
obligatoirement s'authentifier en introduisant son login et son mot de passe. En cas de succès il est
dirigé vers la section qui lui convient selon les droit d'accès sinon un message d’échec est affiché.

2.2 Fenêtre de saisie des prêts et

d’impression des contrats.

2.3 Fenêtre d’envoi de messages pour les rappels d’échéance, rappels d’impayés, mises en
demeure, etc.
2.4 Fenêtre d’importation des fichiers Excel pour l’envoi de divers messages.

CONCLUSION GENERALE
Ce projet nous a permis d'avoir un aperçu sur le cycle complet du développement de logiciel,
de la conception à la validation en passant par les tests.

Notre étude a comporté deux grandes parties à savoir le volet conception et le volet
réalisation.

Sur le plan conceptuel nous avons utilisé la modélisation MERISE.

Sur le plan pratique, cette application a été réalisée avec le Système de Gestion Bases de
Données de PostgreSQL et le langage de programmation WinDev.

Nous avons donc eu l'opportunité d'approfondir nos connaissances que ce soit au plan
scientifique ou personnel.

Nous avons logiquement connu certaines difficultés au niveau de la modélisation conceptuelle

et également au niveau de la programmation. Cependant, nous avons essayé de dégager les
solutions les mieux adaptées afin d’atteindre nos objectifs. Ces solutions ne prétendent
nullement être les meilleures. C’est pourquoi nous pensons que cette application peut être
améliorée.