Mise en place d’une solution d’aide à la décision pour PFE/2011_12/Nesrine Dhraief... · Les...

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université de Carthage

*-*-*-*-*

Ecole Supérieure de la Statistique et de l’Analyse de l’Information

Projet de fin d’études

POUR L’OBTENTION DU DIPLOME NATIONAL D’INGENIEUR EN STATISTIQUE ET ANALYSE DE

L’INFORMATION

Réalisé par Encadré par

DHRAIEF Nesrine M. BESSA Mohamed

M. BOUNDI Ameur

Année universitaire 2011-2012

Mise en place d’une solution d’aide à la décision pour

le suivi des impayés

Remerciements

Au terme de ce travail, il m’est agréable de m’acquitter d’une dette de reconnaissance

auprès de toutes les personnes dont l’intervention au cours de ce stage, a favorisé son

aboutissement.

C’est avec gratitude et respect que je tiens à exprimer mes profonds remerciements à M.

BENYOUSSEF Adel, Directeur Central des Affaires Juridiques et du Recouvrement, de

m’avoir accordé l’opportunité de passer ce stage au sein de sa direction, de m’avoir intégrée

dans son équipe et de m’avoir conseillée et aidée tout au long du stage.

Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance aux

personnes suivantes, pour l’expérience enrichissante et pleine d’intérêt qu’elles m’ont fait

vivre tout au long de la période du stage ainsi que pour leur disponibilité, conseils et suivi :

Mon encadrant universitaire M. BESSA Mohamed ainsi que mon encadrant professionnel

M.BOUNDI Ameur.

Je tiens aussi à remercier tous ceux qui m’ont toujours soutenue et qui ont pris part de leur

temps pour m’aider à élaborer ce travail.

Mes derniers remerciements et non les moindres, iront à mes proches, et en particulier à

mon père et ma mère qui m’ont toujours apporté leur soutien sans faille. Je les remercie de

toute l’affection et tout l’amour qu’ils m’ont témoigné.

Dédicaces

A ma chère mère Farida,

Pour ses sacrifices, sa tendresse et sa patience illimitée, que ce travail

soit le témoignage de mon grand amour et qu'il fasse l'objet de ta

fierté.

A mon cher père Jalel à qui je dois tout,

Qui a cru en moi et m'a soutenue par ses précieux conseils,

Puisse Dieu te garder et te permettre de jouir du produit de tes efforts.

A Mon cher fiancé Mehdi,

Pour tout l'amour et le soutien que tu m'as offert.

A mes frères et sœur,

A tout mes amis,

Pour tous les instants inoubliables que j'ai passés avec vous. Je vous

souhaite le succès dans vos vies.

A tous ceux que j'aime et qui m'aiment.

Je dédie ce travail espérant avoir répondu à leurs souhaits de me voir

réussir.

Résumé

Les tableaux de bord constituent aujourd’hui un outil incontournable de la stratégie

d’entreprise et des systèmes d’aide à la décision. Les tableaux de bord sont en effet le

composant clé d'un management de la performance maitrisé.

La maîtrise de la conception des tableaux de bord conditionne la réussite de la mise en place

d'une stratégie gagnante.

Les tableaux de bord assistent les managers dans n’importe quel niveau de l’organisme, et

fournissent la vue d’ensemble dont les décideurs ont besoin pour contrôler l’état et les

opportunités des affaires. Ils peuvent aussi supporter l’interaction avec les données, comme la

fouille dans les détails profonds de ces dernières pour tirer l’information utile.

Ce projet vise à implémenter cet instrument dans le but de mesure de la performance et

d’amélioration du processus de prise de décision dans le domaine de recouvrement.

Table des matières

Introduction générale ................................................................................................................. 1

Chapitre : Contexte général ..................................................................................................... 3

I. Présentation de l’organisme d’accueil : « Arab Tunisian Bank » ................................... 4

I.1 Historique .................................................................................................................... 4

I.2 Fiche d’identité ............................................................................................................ 5

I.3 Les réseaux d’agence et perspectives d’avenir ........................................................... 5

I.4 Organigramme de l’ATB ............................................................................................. 7

II. Présentation de la Direction Centrale des Affaires Juridiques et du Recouvrement ....... 8

II.1 Division Recouvrement ............................................................................................ 8

II.2 Division Affaires Juridiques..................................................................................... 9

II.3 Division Garanties ................................................................................................... 9

II.4 Division Administrative et Relations Extérieures .................................................... 9

III. Présentation du projet ............................................................................................... 10

III.1 Cadre du projet ...................................................................................................... 10

III.2 Contexte du projet .................................................................................................. 10

III.3 Description du projet ............................................................................................. 10

III.4 Problématique ........................................................................................................ 11

IV. Conclusion ................................................................................................................. 11

Chapitre : Etat de l’art ......................................................................................................... 12

I. Quelques définitions ....................................................................................................... 13

I.1 Tirage ......................................................................................................................... 13

I.2 Effet commercial ........................................................................................................ 13

I.3 Effet financier ............................................................................................................ 13

I.4 Compte gelé ............................................................................................................... 13

II. La classification des actifs et la constitution des provisions ......................................... 14

II.1 La classification des actifs ..................................................................................... 14

II.1.1 Les actifs courants .............................................................................................. 14

II.1.2 Les actifs classés ................................................................................................ 15

II.2 La constitution des provisions ............................................................................... 16

III. La procédure de recouvrement .................................................................................. 17

III.1 L’arrangement ou le recouvrement amiable .......................................................... 17

III.2 La phase précontentieuse ....................................................................................... 18

III.3 La phase contentieuse ............................................................................................ 18

III.3.1 La procédure d’injonction de payer ................................................................... 19

III.3.2 La procédure de droit commun .......................................................................... 19

III.3.3 La procédure de saisie immobilière ................................................................... 19

III.3.4 La procédure de saisie arrêt .............................................................................. 20

IV. Le projet décisionnel ................................................................................................. 20

IV.1 Introduction ............................................................................................................ 20

IV.2 Problématique de l’intégration des données hétérogènes ..................................... 21

IV.2.1 Conflits de représentation .................................................................................. 22

IV.2.2 Conflits de noms (termes) ................................................................................... 22

IV.2.3 Conflits de contextes ........................................................................................... 22

IV.2.4 Conflits de mesure de valeur .............................................................................. 22

IV.3 Data Warehouse : Aspects méthodologiques ........................................................ 22

IV.3.1 Définition d’un Data Warehouse ....................................................................... 22

IV.3.2 Caractéristiques d’un Data Warehouse ............................................................. 23

IV.3.3 Architecture d’un Data Warehouse .................................................................... 25

IV.3.4 Restitution des données ...................................................................................... 26

IV.4 Modélisation multidimensionnelle ......................................................................... 27

IV.4.1 Dimension ........................................................................................................... 27

IV.4.2 Fait ..................................................................................................................... 28

IV.4.3 Mesure ................................................................................................................ 28

IV.4.4 Étoile .................................................................................................................. 28

IV.4.5 Flocon ................................................................................................................. 28

V. Conclusion ................................................................................................................. 29

Chapitre : Etude de l’existant et spécification des besoins ................................................. 30

I. Etude de l’existant .......................................................................................................... 31

I.1 Contexte de l’ATB ...................................................................................................... 31

I.2 Architecture fonctionnelle actuelle du système de suivi des impayés ...................... 32

I.3 Critique de l’existant ................................................................................................. 36

II. Spécification des besoins ................................................................................................ 36

II.1 Enoncé du besoin ................................................................................................... 36

II.2 Besoins fonctionnels ............................................................................................... 37

II.3 Besoins non fonctionnels ........................................................................................ 37

II.4 Architecture fonctionnelle cible du système de suivi des impayés ......................... 38

III. Conclusion ................................................................................................................. 39

Chapitre : Conception ......................................................................................................... 40

I. Etapes de la phase conceptuelle ..................................................................................... 41

I.1 Détermination des objectifs et des scénarios d’analyse ............................................ 41

I.2 Choix des mesures ou des indicateurs ....................................................................... 42

I.3 Choix des dimensions ................................................................................................ 43

I.4 La table de faits ......................................................................................................... 43

I.5 Modélisation du Datamart IMPAYES ....................................................................... 44

I.6 Etude des données sources ........................................................................................ 45

I.7 Le mapping ................................................................................................................ 48

II. Le tableau de bord .......................................................................................................... 50

II.1 Rapports d’analyse des impayés financiers ........................................................... 51

II.1.1 Schéma ............................................................................................................... 51

II.1.2 Table des dimensions ......................................................................................... 52

II.1.3 Table des agrégations ........................................................................................ 53

II.2 Rapport d’analyse des impayés commerciaux ....................................................... 54

II.2.1 Schéma ............................................................................................................... 54



II.3 Rapport d’analyse des comptes gelés .................................................................... 57

II.3.1 Schéma ............................................................................................................... 57



III. Conclusion ................................................................................................................. 59

Chapitre : Réalisation ........................................................................................................... 60

I. Environnement et outils de travail ................................................................................. 61

I.1 Environnement matériel ............................................................................................ 61

I.2 Environnement logiciel .............................................................................................. 61

I.2.1 Outils de conception MERISE : Sybase Power AMC 15.1 ............................... 61

I.2.2 SGBD : Oracle10g ............................................................................................. 61

I.2.3 Outil décisionnel : Qlikview 11 .......................................................................... 62

II. Validation et expérimentation ........................................................................................ 62

II.1 Création du Datamart ............................................................................................ 62

II.2 Chargement des données dans Qlikview ................................................................ 63

II.3 Interfaces homme machine..................................................................................... 64

II.3.1 Ecran d’accueil .................................................................................................. 65

II.3.2 Ecran de la situation générale des impayés ....................................................... 66

II.3.3 Ecran de la situation des impayés financiers ..................................................... 67

II.4 Chronogramme ...................................................................................................... 68

III. Conclusion ................................................................................................................. 69

Conclusion générale et perspectives ........................................................................................ 70

Glossaire .................................................................................................................................. 72

Bibliographie ............................................................................................................................ 74

Nétographie .............................................................................................................................. 75

liste des figures

Figure 1. Organigramme de l'ATB............................................................................................. 7

Figure 2. Organigramme de la direction centrale de recouvrement et des affaires juridiques. 8

Figure 3. La chaine décisionnelle ............................................................................................ 21

Figure 4. Architecture fonctionnelle d'un Data Warehouse .................................................... 25

Figure 5. Schéma en étoile ....................................................................................................... 28

Figure 6. Schéma en flocon de neige ....................................................................................... 29

Figure 7. Architecture fonctionnelle actuelle du système de suivi des impayés ...................... 35

Figure 8. Architecture fonctionnelle cible du système de suivi des impayés ........................... 39

Figure 9. Table de faits fact_impaye ........................................................................................ 43

Figure 10. Datamart IMPAYES ............................................................................................... 44

Figure 11. Rapport d'analyse des impayés financiers ............................................................. 51

Figure 12. Rapports d'analyse des impayés commerciaux ...................................................... 54

Figure 13. Rapports d'analyse des comptes gelés .................................................................... 57

Liste des interfaces

Interface 1. Première interface Oracle .................................................................................... 32

Interface 2. Deuxième interface Oracle ................................................................................... 33

Interface 3. Interface EQUATION ........................................................................................... 33

Interface 4. Application de suivi des impayés financiers ......................................................... 34

Interface 5. Script SQL pour la création de la table FACT_IMPAYE ..................................... 62

Interface 6. Visionneur de tables .............................................................................................. 63

Interface 7. Script pour le chargement des données dans Qlikview ........................................ 64

Interface 8. Ecran d'accueil ..................................................................................................... 65

Interface 9. Ecran de la situation générale .............................................................................. 66

Interface 10. Ecran de la situation des crédits ......................................................................... 67

Liste des tableaux

Tableau 1. Fiche d'identité de l'ATB -------------------------------------------------------------------- 5

Tableau 2. Objectifs et scénarios d'analyse ---------------------------------------------------------- 42

Tableau 3. Mesures retenues ---------------------------------------------------------------------------- 42

Tableau 4. Dimensions retenues ------------------------------------------------------------------------ 43

Tableau 5. Table client----------------------------------------------------------------------------------- 45

Tableau 6. Table compte client ------------------------------------------------------------------------- 45

Tableau 7. Table garantie ------------------------------------------------------------------------------- 45

Tableau 8. Table impayé finanicer --------------------------------------------------------------------- 46

Tableau 9. Table impayé commercial ----------------------------------------------------------------- 46

Tableau 10. Table encours credit ---------------------------------------------------------------------- 46

Tableau 11. Table cumul crédit mensuel -------------------------------------------------------------- 47

Tableau 12. Table cumul crédit quotidien ------------------------------------------------------------ 47

Tableau 13. Table agios débit -------------------------------------------------------------------------- 47

Tableau 14. Table solde du compte -------------------------------------------------------------------- 47

Tableau 15. Table liste chef de zone ------------------------------------------------------------------- 48

Tableau 16. Mapping de la table dim_cpte_clt------------------------------------------------------- 48

Tableau 17. Mapping de la table dim_client --------------------------------------------------------- 49

Tableau 18. Mapping de la table dim_dossier ------------------------------------------------------- 49

Tableau 19. Mapping de la table dim_garantie ------------------------------------------------------ 50

Tableau 20. Mapping de la table dim_recouvreur --------------------------------------------------- 50

Tableau 21. Mapping de la table dim_zone ----------------------------------------------------------- 50

Tableau 22. Table des dimensions des impayés financiers ----------------------------------------- 52

Tableau 23. Table des agrégations des impayés financiers ---------------------------------------- 53

Tableau 24. Table des dimensions des impayés commerciaux ------------------------------------- 55

Tableau 25. Table des agrégations des impayés commerciaux ------------------------------------ 56

Tableau 26. Table des dimensions des comptes gelés ----------------------------------------------- 58

Tableau 27. Table des agrégations des comptes gelés ---------------------------------------------- 59

Tableau 28. Chronogramme de la planification des tâches du projet ---------------------------- 68

Liste des annexes

Annexe A : Dictionnaire complet des données sources ............................................................ 77

Annexe B : Présentation de Qlikview ....................................................................................... 83

Nesrine Dhraief -- Projet de Fin d’études 2011/2012

1 Introduction générale | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

Introduction générale

Réussir une activité à but lucratif, c’est avant tout avoir le sens de l’organisation, de la

gestion et de la maîtrise de l’information. Ce que vit le monde de la bourse actuellement et le

déséquilibre que subit une majorité des institutions financières ne sont autres que l’œuvre

d’une déficience du monde de l’information relative à ces activités.

C’est pour cela que l’information est considérée comme le moteur poussant et le cœur battant

relative à chaque entreprise compte tenu des renseignements offerts visant à éclaircir les

tenants d’un projet quelconque. En outre, elle représente les éléments significatifs pour la

personne qui la reçoit et constitue une valeur réelle pour ses décisions et ses actions.

Actuellement, on ne parle plus d’une information quelconque, mais on parle plutôt de système

d’information qui doit être fiable, pertinent, disponible et normalisé. L’apport de l’outil

informatique a, en toute évidence, accéléré l’évolution du monde de l’information et est

devenu un besoin fondamental facilitant à l’entreprise l’affrontement de la concurrence.

Avec le développement d’Internet et des intranets, l’échange et le partage de l’information

provenant de diverses sources de données réparties, autonomes et hétérogènes deviennent un

besoin crucial. Dans un tel contexte, il est souvent nécessaire pour une application d’accéder

simultanément à plusieurs sources, du fait qu’elles contiennent des informations pertinentes et

complémentaires. Pour ce faire, la solution des systèmes d’intégration a été proposée. Elle

consiste à fournir une interface uniforme et transparente aux données pertinentes via un

schéma global.

Pour le secteur bancaire, le caractère excessif de la durée de certains délais de paiement

ainsi que l’importance des retards constatés dans le règlement des échéances constituent des

pratiques ayant pour effet, pour les institutions qui en sont victimes, d’alourdir leur gestion

financière, d’affecter leur rentabilité et même, dans certains cas, de menacer leur survie.

C’est pour cette raison que le métier du recouvrement qui se définit par l’ensemble des

moyens mis en œuvre pour se faire rembourser les créances nées suite à des crédits accordés à

la clientèle nécessite de disposer d’un système d’information sécurisé, fiable, ergonomique, et

capable d’améliorer le processus d’aide à la décision.


2 Introduction générale | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

C’est dans ce cadre que s’insère notre projet intitulé « Mise en place d’une solution d’aide

à la décision pour le suivi des impayés » et qui consiste à mettre en place une application

intégrée d’aide à la décision spécifique à la direction des affaires juridiques et du

recouvrement et qui permet de suivre les impayés et les comptes gelés de l’ATB.

Le présent rapport de projet de fin d’études s’articule autour de cinq chapitres :

Le premier chapitre est dédié à la présentation du projet et de son contexte général.

Le deuxième chapitre présente l’état de l’art du projet.

Le troisième chapitre est consacré à l’analyse de l’existant et à la spécification des

différents besoins fonctionnels et non fonctionnels.

Le quatrième chapitre est consacré à la conception générale et détaillée de

l’application à mette en place.

Le dernier chapitre traite la phase de réalisation de l’application ainsi qu’une autre

phase allouée à la validation et l’expérimentation de cette même application.


3 Chapitre I : Contexte général | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

Chapitre : Contexte général

I. Présentation de l’organisme

II. Présentation du lieu du stage

III. Présentation du projet

IV. Conclusion



Ce chapitre est consacré à la présentation de l’organisme d’accueil « Arab Tunisian Bank »

et à la présentation du projet et plus précisément son contexte ainsi que la problématique qui

nous a donné l’idée de créer une telle application.

I. Présentation de l’organisme d’accueil : « Arab Tunisian Bank »

I.1 Historique

L’Arab Tunisian Bank est une banque commerciale de droit Tunisien. Elle a été créée le 30

Juin 1982 par l’intégration de la succursale de l’Arab Bank Plc, sise à Tunis depuis 1952 à

l’apport de personnes physiques Tunisiennes dans le cadre de renforcer sa présence dans le

monde arabe. Elle s’est donnée pour mission de contribuer au développement économique et

financier des pays arabes, en offrant aux professionnels un service diversifié et de qualité.

La croissance de l’Arab Bank s’est faite dans une région qui connaissait à la fois des

troubles politiques et un développement économique spectaculaire. L’accession des pays de la

région à leur indépendance et leur besoin d’un support pour se développer en ont été les

principaux moteurs. Le succès de la banque n’a pas surpris son fondateur.

En effet, l’ARAB BANK PLC a été fondé en 1930 à Amman en Jordanie par Monsieur

ABDELHAMID SHOMAN, ce fut la deuxième banque. Sa politique était d’implanter des

succursales un peu partout dans le monde arabe. Cette banque s’est développée énormément

et devenue un groupe d’une importance majeure dont les filiales sont aujourd’hui implantées

dans 45 pays.

Depuis 1982, le réseau de l’ATB n’a cessé de développer pour atteindre au terme 30 ans,

128 agences implantées sur tout le territoire tunisien en employant 999 personnes.



I.2 Fiche d’identité

Comme toute banque, l’ATB dispose d’une fiche signalétique :

Dénomination L’ARAB TUNISIAN BANK

Siège Social 9 Rue Hedi Nouira, 1001 Tunis

Forme juridique Société Anonyme

Date de Création 30 juin 1982

Capital social

100 000 Dinars devisé en action

de valeur nominale de 10D

PNB au 31/12/2009 125 014(Unité : en 1000 DT)

PNB au 31/12/2010 143 998(Unité : en 1000 DT)

Résultat au 31/12/09 45 815(Unité : en 1000 DT)

Résultat au 31/12/10 53 509(Unité : en 1000 DT)

Nombre d’agences 128

Nombre d’employées 999

Objet Social Commerce de banque

Régime Fiscale Droit commun

Registre de Commerce 47496

Téléphone 71351155

E-mail [email protected]

Site Internet www.atb.com.tn

Tableau 1. Fiche d'identité de l'ATB

I.3 Les réseaux d’agence et perspectives d’avenir

L’architecture générale du réseau commercial de la banque en Tunisie est fondée sur une

orientation «marché». C’est ainsi que la couverture géographique du pays est assurée par un

réseau d’agences implantées dans les principaux d’affaires du pays.

L’objectif de croissance visé par la banque, sera réalisé conformément à une stratégie

commerciale bâtie autour des axes principaux suivants:

Le renforcement du réseau pour soutenir la collecte des ressources.

L’offre à la clientèle d’une gamme de produits et services diversifiée et compatible

avec l’évolution technologique.

La recherche de synergie entre la banque, ses filiales et sa clientèle.

http://www.atb.com.tn/



La consolidation du bon positionnement de la banque dans le secteur.

L’offre à la clientèle de tous les composants monétiques:

La mise en place d’un bouquet de sites web spécialisés et dédies aux différents clients

(enfants, jeunes, femmes, hommes, particuliers, professionnels et entreprises).



I.4 Organigramme de l’ATB

L’ATB est une société anonyme dirigée par un conseil d’administration composé d’un

Président, de deux Vice-présidents, de cinq administrateurs représentants de l’Arab Bank

PLC, cinq administrateurs Tunisiens du conseil et d’un commissaire aux comptes.

L’organisation de l’ATB est représenté par l’organigramme suivant :

Figure 1. Organigramme de l'ATB



II. Présentation de la Direction Centrale des Affaires

Juridiques et du Recouvrement

L’organigramme du lieu du stage se présente comme suit :

Figure 2. Organigramme de la direction centrale de recouvrement et des affaires juridiques.

II.1 Division Recouvrement

Les principales tâches exécutées par les agents responsables dans la division recouvrement

sont notamment:

Contacter l’agence concernée du client défaillant.

Constituer le dossier à instruire en collectant les différents documents y relatifs

(dossier juridique, dossier de crédit, dossier de garantie).

Entrer directement en relation avec la relation (le client), ou à travers l’agence et

établir des scénarios d’action.

Elaborer une proposition d’arrangement.

Assurer le suivi des consolidations et la relance des clients.

Transférer des dossiers à la société de recouvrement sous-traitante.



II.2 Division Affaires Juridiques

Les responsables de cette division doivent remplir les tâches suivantes:

L’étude et la rédaction des actes juridiques de la banque.

L’élaboration des études juridiques relatives à toute nouvelle loi/réglementation, à une

nouvelle activité ou à un nouveau produit de la banque.

La rédaction des conventions et des actes juridiques.

La réponse aux consultations des différentes unités de la banque (Directions et

agences).

La mise à jour du cadre juridique lors des publications relatives aux nouvelles lois,

décrets, arrêtés et circulaires.

Donner un avis juridique sur les contrats.

II.3 Division Garanties

Les responsables de cette division doivent :

Réceptionner les Notifications Provisoires de Crédit (NPC).

Recevoir et vérifier les documents juridiques transmis pour la constitution des

garanties.

Etudier les documents nécessaires à la constitution des garanties: vérifier l’existence

des documents requis ainsi que les formalités nécessaires pour la constitution des

garanties.

Procéder à la relance des clients, à travers l’agence concernée, et rappeler les

documents manquants.

Elaborer le contrat de prêt et assurer le suivi de sa signature.

Procéder au calcul des frais d’enregistrement auprès de la recette des finances.

II.4 Division Administrative et Relations Extérieures

Cette division est subdivisée en deux services :

Service des Relations Extérieures

Les opérations effectuées dans ce service sont:

Le suivi des dossiers de garanties auprès de la Conservation de la Propriété Foncière

(CPF) et du tribunal immobilier.

La constitution et l’inscription de la garantie.

Le dépôt du contrat hypothécaire.



Le retrait des certificats de propriétés.

Le suivi des dossiers rejetés par la CPF.

Le retrait des pièces nécessaires pour l’inscription des dossiers auprès des organismes

compétents (Municipalité, recette des finances…).

Service Saisies Arrêts

Ce service assure :

La gestion des saisies arrêts et des oppositions à denier.

La gestion relative aux décisions de jugement prononcé à l’encontre des clients.

La gestion des réquisitions judiciaire sollicitées par la Brigade Economique, Brigade

de Sureté de l’Etat, Brigade Criminelle, Brigades des Stupéfiants etc.

III. Présentation du projet

III.1 Cadre du projet

Ce travail s’inscrit dans le cadre du projet de fin d’études en vue de l’obtention du Diplôme

National d’Ingénieur en Statistique et Analyse de l’Information. Ce projet, de durée quatre

mois, est effectué au sein de l’ATB : Arab Tunisian Bank. Son objectif est la mise en place

d’une application intégrée d’aide à la décision pour le suivi des impayés et des comptes gelés.

III.2 Contexte du projet

Aujourd’hui, le recouvrement de créances impayées ne se conçoit pas sans l’aide d’une

application spécialisée. Dans le cadre de l’amélioration du processus de recouvrement, l’ATB

se propose de mettre en place une application intégrée qui l’aide à mieux suivre ses créances

impayées.

Ce projet consiste en une application intégrée, qui permet le suivi en temps réel et continu de

la situation des créances impayées, en essayant d’appliquer le meilleur arrangement avec le

client et des poursuites judiciaires en cas de défaut.

III.3 Description du projet

Le travail consiste à concevoir un entrepôt regroupant les données qui concernent les

impayés financiers, les impayés commerciaux et les comptes gelés des clients ATB, à faire la

classification quotidienne de ces créances en se basant sur des règles fixées par la Banque

Centrale de Tunisie, et enfin à créer un tableau de bord destiné aux décideurs du département

des affaires juridiques et du recouvrement et qui sera alimenté par l’entrepôt de données déjà



conçu. Ce tableau de bord permettra de suivre à la trace l’état des impayés et des comptes

gelés. Cela donnera le moyen aux membres de bien apprécier les problèmes rencontrés, de

participer à la prise de la décision ainsi que de s’investir dans d’éventuels plans d’ajustement.

L’application à créer ne doit pas communiquer directement avec la base de données du

système d’information de production, mais avec une base de données intermédiaire qui sera le

point de liaison entre la base de données du système d’information et l’application d’aide à la

décision.

Le projet se divise donc en deux parties principales :

Intégration de ces différentes informations par l’intermédiaire de l’entrepôt de

données.

Création d’un tableau de bord qui communique avec cet entrepôt et qui donne

l’opportunité de générer des rapports automatiques pour des fins d’analyse et de

suivi.

III.4 Problématique

L’application décrite ci-dessus doit répondre à trois objectifs qui sont les suivants :

Assurer la mise à jour automatique et planifiée de l’entrepôt de données avec lequel le

tableau de bord va communiquer.

Assurer aux personnes intervenant dans la procédure de recouvrement et disposant

d’une connexion intranet, de se connecter au serveur de la banque, et d’utiliser

l’application.

Avoir une vue globale sur toutes les données via une interface unique et possibilité de

générer des rapports automatiques selon le besoin de l’utilisateur.

IV. Conclusion

Ce chapitre constitue une partie introductive dans laquelle une présentation des grandes

lignes du sujet a été établie. Nous avons présenté l’organisme d’accueil, le contexte général

du projet et la problématique liée.

Compte tenu de cela, nous allons présenter dans le chapitre qui suit, l’état de l’art du projet

et les différentes notions qui y sont liées.


12 Chapitre II : Etat de l’art | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

Chapitre : Etat de l’art

I. Quelques définitions

II. La classification des actifs et la constitution des provisions

III. La procédure de recouvrement

IV. Le projet décisionnel

V. Conclusion



Après avoir présenté le projet, son cadre général et la problématique associée, nous

consacrons ce chapitre à l’état de l’art pour mettre en évidence l’importance des projets

décisionnels liés aux domaines du recouvrement.

I. Quelques définitions

I.1 Tirage

Le « tirage » est l’acte par lequel le créancier dit le « tireur » ou encore le créancier

bénéficiaire crée une lettre de change ou un billet à ordre que le débiteur des sommes dues dit

« tiré » devra régler à l’échéance.

I.2 Effet commercial

L’expression effet commercial est la plus couramment utilisée pour désigner l’instrument de

paiement à terme d’une transaction commerciale. Les effets de commerce sont des écrits qui

peuvent porter le nom de lettre de change ou de traite.

Le but premier des effets de commerce est le paiement différé d’une dette ou d’une

obligation, contractée à court terme entre des commerçants.

Il a encore pour but de faciliter les opérations impliquant la prestation, son paiement et les

recours des parties. Il est important de préciser que les traites sont beaucoup utilisées pour des

opérations commerciales dans le cadre de l’exploitation d’une entreprise.

I.3 Effet financier

Il s’agit d’un titre par lequel une personne dénommée souscripteur, s’engage à payer à une

échéance déterminée, une somme d’argent à l’ordre d’une autre personne dénommée

bénéficiaire (la banque) d’où la dénomination billet à ordre. L’effet financier est d’usage

moins courant que l’effet commercial. Il est surtout utilisé comme instrument de mobilisation

des créances bancaires.

I.4 Compte gelé

Lorsqu’il est écoulé un délai de 90 jours après l’arrêté des intérêts sans que le compte

n’enregistre des mouvements de recettes susceptibles de compenser le montant intégral des

intérêts débiteurs et autres charges, le découvert (ou le compte débiteur) est dit gelé.



II. La classification des actifs et la constitution des provisions

Les banques sont tenues de procéder à la classification de tous leurs actifs quelle qu’en soit

la forme, qu’ils figurent au bilan ou en hors bilan et qu’ils soient libellés en dinars.

Il demeure entendu que la constitution des provisions s’opère compte tenu des garanties

reçues de l’état, des organismes d’assurance et des banques ainsi que des garanties sous forme

de dépôts ou d’actifs ou d’actifs financiers susceptibles d’être liquidés sans que leur valeur ne

soit affectée.

II.1 La classification des actifs

Chaque banque doit exiger, pour le suivi de ses encours financiers aux entreprises ayant

auprès d’elles des risques dépassant 10% de ses fonds propres, un rapport d’audit externe.

Les banques doivent, avant tout engagement, exiger de leurs clientèles dont les engagements

auprès du système financier dépassent cinq millions de dinars, les états financiers

de l’exercice précédant l’année de l’octroi de crédit, certifiés par un commissaire aux comptes

légalement habilité.

Elles doivent, également, exiger les états financiers des exercices qui suivent l’année de

l’octroi de crédit, certifiés aussi par un commissaire aux comptes légalement habilité.

Toutefois, les banques peuvent à l’appui de tout engagement pris au cours des six premiers

mois de l’année de l’octroi de crédit, accepter les états financiers de l’avant dernier exercice à

condition qu’ils soient certifiés par un commissaire aux comptes légalement habilité.

Les banques doivent en sus demander à leur clientèles non cotées en Bourse et dont les

engagements auprès du système financier dépassent vingt cinq millions de dinars, de fournir

une notation récente attribuée par une agence de notation.

Les actifs détenus directement sur l’Etat ou sur la Banque Centrale de Tunisie ne font pas

l’objet de classification. Pour l’évaluation du risque d’insolvabilité, les banques doivent

distinguer leurs actifs du bilan et du hors bilan en actifs courants et actifs classés en fonction

du risque de perte et de la probabilité de recouvrement.

Cette distinction doit faire l’objet d’une mise à jour continue. Ainsi, les actifs classés doivent

obéir à des règles spécifiques en matière de comptabilisation de leurs produits.

II.1.1 Les actifs courants

Sont considérés comme actifs courants, les actifs dont la réalisation ou le recouvrement

intégral dans les délais paraît assuré et qui sont détenus sur des entreprises dont :



La situation financière est équilibrée et confirmée par des documents comptables

certifiés datant de moins de 3 mois.

La gestion et les perspectives d’activité sont jugées satisfaisantes sur la base des

rapports de visites.

La forme et le volume des concours dont elles bénéficient sont compatibles tant avec les

besoins de leur activité principale qu’avec leur capacité réelle de remboursement.

II.1.2 Les actifs classés

Classe 1 : Actifs nécessitant un suivi particulier

Font partie de la classe 1, tous les actifs dont la réalisation ou le recouvrement intégral dans

les délais est encore assuré et qui sont détenus sur des entreprises qui présentent l’une au

moins des caractéristiques suivantes :

Le secteur d’activité connaît des difficultés.

La situation financière se dégrade.

Classe 2 : Actifs incertains

Appartiennent à la classe 2, tous les actifs dont la réalisation ou le recouvrement intégral dans

les délais est incertain et qui sont détenus sur des entreprises qui connaissent des difficultés

financières ou autres pouvant mettre en cause leur viabilité et nécessitant la mise en œuvre de

mesures de redressement.

Outre les caractéristiques définies à la classe 1, ces entreprises présentent l’une au moins de

celles qui suivent :

La forme et le volume des encours ne sont plus compatibles avec leur activité

principale.

L’évaluation de la situation financière ne peut plus être mise à jour à cause d’une

défaillance au niveau de la disp0onibilité de l’information ou de la documentation

nécessaire.

L’existence de problèmes de gestion ou de litiges entre associés.

L’existence de difficultés d’ordre technique, de commercialisation ou

d’approvisionnement.

La détérioration du cash flow qui compromet, en l’absence d’autres sources de

financement, le remboursement des dettes dans les délais.

L’existence de retards de paiement des intérêts ou des principaux supérieurs à 90 jours

sans excéder 180 jours.



Font également partie de la classe 2, les autres actifs restés en suspens et non apurés dans un

délai de 90 jours sans excéder 180 jours.

Classe 3 : Actifs préoccupants

Appartiennent à la classe 3 tous les actifs dont la réalisation ou le recouvrement est menacé et

qui sont détenus sur des entreprises dont la situation suggère un degré de pertes éventuelles

appelant une action vigoureuse de la part de la banque pour les limiter au minimum. Ces actifs

sont généralement détenus sur des entreprises qui présentent avec plus de gravité, les

caractéristiques de la classe 2.

Les retards de paiements des intérêts ou du principal sont généralement supérieurs à 180 jours

sans excéder 360 jours. Font également partie de la classe 3, les autres actifs restés en suspens

et non apurés dans un délai de 180 jours sans excéder 360.

Classe 4 : Actifs compromis

Font partie de la classe 4 :

Les créances pour lesquelles les retards de paiements des intérêts ou du principal sont

supérieurs à 360 jours.

Les actifs restés en suspens au-delà de 360 jours.

Les autres actifs qui doivent être passés par pertes. La banque est tenue néanmoins

d’épuiser toutes les procédures de droit tendant à la réalisation de ces actifs.

II.2 La constitution des provisions

Selon l’article 10 de la circulaire de la Banque Centrale, les banques doivent constituer des

provisions au moins égales à 20% pour les actifs de la classe 2, 50% pour les actifs de la

classe 3 et 100% pour les actifs de la classe 4.

Ces provisions doivent être affectées spécifiquement à tout actif classé égal ou supérieur à 50

milles dinars ou à 0,5% des fonds propres nets.

Les biens meubles et immeubles données en garantie par les emprunteurs ne sont considérés

comme des garanties valables que dans le cas où la banque dispose d’une hypothèque dûment

enregistrée et que des évaluations indépendantes et fréquentes de ces garanties sont

disponibles.

En outre, la possibilité d’une liquidation rapide sur le marché au prix d’évaluation doit être

assurée.



III. La procédure de recouvrement

Les clients sont la raison d’exister des entreprises et ils constituent une grande part de leur

richesse. Mais ces mêmes clients peuvent parfois devenir les acteurs conduisant les

entreprises à leur perte si ceux-ci se transforment en mauvais payeurs. Les impayés, les

retards de paiement et le gel des comptes constituent en effet l’une des principales causes de

défaillance des entreprises. Il est donc important de veiller rapidement au bon règlement des

créances clients en cours afin de ne pas mettre en péril la situation de son entreprise.

La bonne gestion du poste client est un des enjeux les plus importants pour la pérennité d’une

entreprise et passe par une bonne organisation de son processus de recouvrement de ses

créances.

Il est facile de comprendre le besoin d’une bonne gestion du poste client lorsque l’on calcule

l’incidence financière qui peut affecter la rentabilité d’une entreprise, entre autres, le coût du

montant des créances irrécouvrables et celui des intérêts financiers dus au retard de paiement.

Le responsable de la gestion du poste client devra avoir une maitrise approfondie d’une part

de certains aspects de la comptabilité et d’autre part du droit commercial des sociétés.

Le recouvrement des créances est une procédure administrative interne à un organisme

bancaire ou à un établissement de crédit afin de recouvrir une dette impayée ou un compte

gelé de la part d’un client débiteur. C’est la démarche qu’un créancier entame afin de

récupérer de son débiteur la dette d’argent qu’il a contracté.

Les moyens mis en œuvre pour recouvrer les créances sont fonction de l'importance des

sommes dues, de la nature et de l'ancienneté des échéances et de la solvabilité du client.

Afin d’optimiser les chances de recouvrement de la créance, il convient de respecter les

procédures suivantes.

III.1 L’arrangement ou le recouvrement amiable

La phase de recouvrement amiable consiste à délivrer des messages de relance courtois

mais fermes pour inciter le client mauvais payeur à :

Régulariser sa créance impayée.

Comprendre les causes de non paiement.

Identifier les litiges.

Ces relances amiables prennent la forme de lettres de recouvrement, de relances

téléphoniques ou de visites domiciliaires au client débiteur pour le montant de la créance

http://www.netpme.fr/recouvrement-creances/520-10-conseils-fournisseurs-qui-veulent-etre-payes-mieux-possible.html



impayée en principal et en intérêts. L’envoi d’une mise en demeure avec accusé de

réception fait courir les intérêts légaux ou conventionnels à compter de cette date.

Le recouvrement amiable de créances passe aussi obligatoirement par le télé-

recouvrement qui consiste à contacter le client débiteur par téléphone.

Pour que le recouvrement amiable des impayés soit efficace, il est impératif d’alterner les

actions de relances et de les effectuer aux dates convenues. Ces actions doivent être

programmées, scénarisées et s’inscrivent obligatoirement dans la continuité et la progressivité

des messages.

Il est par ailleurs essentiel de maîtriser tous les rouages d’une bonne négociation

commerciale afin de contraindre votre client débiteur de procéder aux règlements amiables de

ses dettes.

III.2 La phase précontentieuse

Cette procédure extrajudiciaire consiste à notifier au débiteur récalcitrant que l’utilisation

des voies légales de recouvrement par la banque est en voie d’être mise en place (format

papier).

Cette notification peut prendre la forme soit d’une lettre simple l’invitant à régulariser sa

situation dans une première étape, soit sous la forme d’une lettre de mise en demeure

accordant à la relation un délai pour proposer un arrangement amiable.

Cette notification peut être déléguée à un auxiliaire de justice sous la forme d’une sommation.

Ces notifications combinées ou non peuvent amener la relation à la table de négociation

(archivage papier et multiplicité des intervenants).

III.3 La phase contentieuse

Le recouvrement contentieux, dit aussi « judiciaire », permet de recourir aux saisies sur le

patrimoine du débiteur, mais nécessite l'obtention d'un titre exécutoire. La phase de

recouvrement judiciaire se révèle très encadrée, et engendre un délai d'action nécessairement

plus long que le recouvrement amiable.

Le débiteur sera alors contraint au règlement de sa dette. On a recours à trois procédures :

La procédure d’injonction de payer.

La procédure de droit commun (assignation en paiement).

La procédure de saisie immobilière.

La procédure de saisie arrêt.



III.3.1 La procédure d’injonction de payer

Cette procédure est la voie par laquelle un créancier peut obtenir promptement un titre

exécutoire, c'est-à-dire une décision judiciaire de condamnation de son débiteur au paiement

de sa créance. Elle est prévue par l’acte uniforme portant organisation des procédures

simplifiées de recouvrement et des voies d’exécution.

Le recours à cette procédure suppose néanmoins pour le créancier, la détention d’une créance

certaine, liquide et exigible. La juridiction territorialement compétente pour connaître de cette

procédure, est celle du domicile du débiteur. Le créancier devra alors déposer une requête en

personne ou par le biais de son mandataire, au greffe de cette juridiction.

La décision de cette juridiction qui est susceptible d’opposition, peut être une décision

d’injonction de payer ou de rejet. Lorsqu’il s’agit d’une décision de rejet, ce rejet peut être

total ou partiel. En cas de décision d’injonction de payer, la cellule de recouvrement judiciaire

reste toujours ouverte à un règlement amiable, si le débiteur le propose.

III.3.2 La procédure de droit commun

C’est la seule voie de recours qui s’offre au créancier en cas de rejet de la requête aux fins

d’injonction de payer, il s’agit alors pour ce dernier, d’assigner le débiteur en paiement devant

le tribunal de son domicile. En cas de jugement de condamnation au paiement total ou partiel

de la créance, le débiteur, ses coobligés et héritiers le cas échéant, peuvent être également

condamnés à payer. Le débiteur qui dispose alors d’un délai d’un mois pour faire appel, peut

voir la juridiction d’appel infirmer ou confirmer le jugement. Dans l’hypothèse d’un arrêt

confirmatif, le débiteur dispose d’un délai d’un mois pour se pourvoir en cassation.

III.3.3 La procédure de saisie immobilière

Cette procédure peut s’avérer inévitable, surtout en matière de prêt immobilier. Elle consiste

pour un créancier de poursuivre la vente par expropriation forcée des immeubles appartenant

à son débiteur défaillant ou de ceux affectés à sa créance.

Longue et coûteuse, la procédure de saisie immobilière n’est possible que pour les créances

constatées par un titre exécutoire. Ce titre en effet demeure au centre de toute la procédure de

saisie immobilière. C’est d’ailleurs le titre sans lequel aucune saisie immobilière n’est

possible.

A preuve, à peine de nullité, le commandement aux fins de saisie qui marque le point de

départ de la procédure de saisie immobilière, doit contenir une reproduction ou une copie du

titre exécutoire.



III.3.4 La procédure de saisie arrêt

La saisie arrêt est une procédure permettant, à un créancier de bloquer et de rendre

disponibles entre les mains d’un tiers, des sommes ou autres meubles dus à son débiteur, pour

se faire ultérieurement attribuer ces sommes, ou le prix de vente des meubles, jusqu’à

concurrence du montant de sa créance.

En effet, le créancier (généralement des banques) peut être amené à pratiquer une saisie arrêt

sur les sommes dues au débiteur et sur les objets mobiliers lui appartenant.

IV. Le projet décisionnel

IV.1 Introduction

La Business Intelligence (informatique décisionnelle) propose d’utiliser les données

transitant par le système d’information, données de production le plus souvent, en

informations susceptibles d’être exploitées à des fins décisionnelles. Sur le plan pratique et

technique, la Business Intelligence se compose d’une famille d’outils informatiques et de pro

logiciels assurant le fonctionnement de la chaîne de traitement de l’information. Il est

coutumier de présenter les éléments composant la chaîne décisionnelle en quatre catégories

correspondant chacune à une fonction spécifique :

1) Collecter, nettoyer et consolider les données, extraire les données des systèmes de

production et les adapter à un usage décisionnel.

2) Stocker, centraliser les données structurées et traitées afin qu’elles soient disponibles

pour un usage décisionnel.

3) Distribuer ou plutôt faciliter l’accessibilité des informations selon les fonctions et les

types d’utilisation.

4) Exploiter ou comment assister du mieux possible l’utilisateur afin qu’il puisse

extraire la substance de l’information des données stockées à cet usage.



Le marché de l'informatique décisionnelle reste en croissance régulière et offre une bonne

visibilité grâce aux progrès technologiques continus, aux nouvelles architectures

informatiques (Internet, client-serveur, SOA), à la mise en place de nouveaux logiciels et aux

nouvelles stratégies d'entreprise (fusion/acquisitions, gestion client).

IV.2 Problématique de l’intégration des données hétérogènes

Les systèmes d’intégration doivent permettre à l’utilisateur d’accéder, via une interface

d’accès unique, à des données stockées dans plusieurs sources de données. Ces sources de

données ont été conçues indépendamment par des concepteurs différents. Cela entraîne

l’hétérogénéité des données, c’est-à-dire que les données relatives à un même sujet sont

représentées différemment sur des systèmes d’information distincts. Cette hétérogénéité

provient des choix différents qui sont faits pour représenter des faits du monde réel dans un

format informatique. En effet, les données sont structurellement indépendantes mais sont

toujours supposées relever de domaines similaires.

La question fondamentale lorsque l’on veut faire inter-opérer des bases de données

hétérogènes est d’une part, l’identification de conflits entre les concepts dans des sources

différentes qui ont des liens sémantiques, d’autre part, la résolution des différences entre les

concepts sémantiquement liés.

Figure 3. La chaine décisionnelle



IV.2.1 Conflits de représentation

Ces conflits se trouvent dans le cas où on utilise des propriétés différentes ou des schémas

différents pour décrire le même concept.

IV.2.2 Conflits de noms (termes)

Ces conflits se trouvent dans le cas où on utilise soit des noms différents pour le même

concept ou propriété (synonyme), soit des noms identiques pour des concepts (et des

propriétés) différents (homonyme).

IV.2.3 Conflits de contextes

Le contexte est une notion très importante dans les systèmes d’information répartis. En effet,

un même objet du monde réel peut être représenté dans les sources de données par plusieurs

représentations selon un contexte local à chaque source. Ces conflits de contexte se trouvent

dans le cas où les concepts semblent avoir la même signification, mais ils sont évalués dans

différents contextes.

IV.2.4 Conflits de mesure de valeur

Ces conflits sont liés à la manière de coder la valeur d’un concept du monde réel dans

différents systèmes. Ils se trouvent dans le cas où on utilise des unités différentes pour

mesurer la valeur de propriétés.

IV.3 Data Warehouse : Aspects méthodologiques

IV.3.1 Définition d’un Data Warehouse

Un Data Warehouse ou un entrepôt de données est une vision centralisée et universelle de

toutes les informations de l'entreprise. C'est une structure (comme une base de données) qui a

pour but, contrairement aux bases de données, de regrouper les données de l'entreprise pour

des fins analytiques et pour aider à la décision stratégique. La décision stratégique étant une

action entreprise par les décideurs de l'entreprise et qui vise à améliorer, quantitativement ou

qualitativement, la performance de l'entreprise. En gros, c'est un gigantesque tas

d'informations épurées, organisées, historisées et provenant de plusieurs sources de données,

servant aux analyses et à l'aide à la décision. L'entrepôt de données est l'élément central de

l'informatique décisionnelle. En effet, l'entrepôt de données est le meilleur moyen que les

professionnels ont trouvé pour modéliser de l'information pour des fins d'analyse.



IV.3.2 Caractéristiques d’un Data Warehouse

Données intégrées : Ce qui caractérise peut-être le plus un Data Warehouse est le fait qu’il

collecte et intègre de la manière la plus automatisée possible des données provenant d’un

ensemble hétérogène de systèmes sources. En vue de permettre des consultations ou des

analyses globales néanmoins fiables au travers de l’ensemble des systèmes, il est nécessaire

de traiter la structure et le contenu des différents apports de données de telle sorte qu’ils soient

rendus cohérents avec ceux du Data Warehouse global.

Données orientées sujet : Une deuxième caractéristique d’un Data Warehouse est d’être

spécifiquement structuré autour de quelques sujets bien déterminés issus de la réalité

organisationnelle, à propos desquels on souhaite récolter des informations et des

connaissances (ex : clients, produits, ventes, ..., ou, dans notre contexte, impayés financiers,

impayés commerciaux, comptes gelés, garanties…).

Données historiées : L’objectif primaire d’un Data Warehouse est de tenir un historique des

faits. Ainsi, la plupart des tables du Data Warehouse comporteront un élément temporel. De

même, le fait de disposer en permanence des informations les plus récentes n’est pas aussi

vital et fait que l’apport des données est moins fréquent.

Données non variables : Une quatrième caractéristique connexe d’un Data Warehouse

consiste à ne plus modifier en principe les données qui y sont stockées; seules de nouvelles

données y sont ajoutées.

Aide à la décision : Enfin, un Data Warehouse a un objectif et un groupe d’utilisateurs

spécifiques : il doit constituer la base d’un système d’aide à la décision. C’est la raison pour

laquelle il n’est pas nécessaire d’y stocker toutes les données. Seules celles susceptibles de

contribuer à l’amélioration des décisions prises suffisent.

Par ailleurs, l’entrepôt de données offre à l’entreprise les principaux avantages suivants :

Il constitue une collection de données centralisée disponible pour l’aide à la décision.

Les évolutions des données de l’entrepôt sont conservées (historisation des données).

Il contient un ensemble de données consolidées (données homogènes et fiables).

Il contient des données agrégées permettant une analyse à différents niveaux de

détails.



Il permet de développer différents thèmes d’analyse (réorganisation en fonction des

sujets à analyser).



IV.3.3 Architecture d’un Data Warehouse

La figure suivante représente l’architecture d’un Data Warehouse.

Nous décrivons les principaux composants de cette architecture dans les points suivants :

Bases de production :

On appelle, de façon générale, bases de production toutes les sources dont il va falloir extraire

des données en vue d’alimenter le Data Warehouse. On y retrouvera notamment, les données

commerciales, les données du système comptable, les données sur le personnel, les

informations sur la concurrence, des informations externes produites par divers organismes

nationaux ou internationaux.

Métadonnées :

La couche métadonnées est fondamentale dans l’architecture du Data Warehouse, elle est la

seule à permettre à l’utilisateur de comprendre la sémantique. On pourrait ainsi définir les

métadonnées, comme étant des informations décrivant les données.

Le dictionnaire de la métadonnée comprend : La description des données sources et cibles, la

description des processus d’alimentation, et le compte rendu d’exécution. Les principales

informations sont destinées : A l’utilisateur (sémantique et localisation), aux équipes

responsables des processus de transformation des données du système de production vers le

Data Warehouse, aux équipes responsables des processus de création des données agrégées à

partir des données détaillées, aux équipes d’administration de la base de données (structure de

Figure 4. Architecture fonctionnelle d'un Data Warehouse



la base implémentant le Data Warehouse), et aux équipes de production (procédures de

changement, historique de mise à jour,…)

Data Mart, ou magasin de données :

Les Data Warehouses étant, en général, très volumineux et très complexes à concevoir, on a

décidé de les diviser en bouchées plus faciles à créer et entretenir. Ce sont les Data Marts. On

peut faire des divisions par fonction (un data mart pour les ventes, pour les commandes, pour

les ressources humaines) ou par sous-ensemble organisationnel.

ETL/Alimentation :

L’outil ETL (Extract, Transform and Load) récupère toutes les données et les centralise dans

une base de données particulière appelée Data warehouse, Datamart ou entrepôt de données.

Les outils ETL permettent de récupérer les données quels que soient leurs sources et les

systèmes qui les supportent (système d’exploitation, SGBD, formats…), d’automatiser et

d’industrialiser le processus d’alimentation, de faciliter la maintenance des données et de

limiter les développements spécifiques. Ces outils permettent de construire, de mettre à jour

et de maintenir le dictionnaire de métadonnées.

IV.3.4 Restitution des données

Les outils de restitution des données sont aussi appelés « outils end-users ». L’outil end-users

est l’élément de l’architecture du système décisionnel le plus important pour l’utilisateur, car

il correspond à l’aspect visible du système.

Parmi les solutions de restitution de données qui existent, nous citons :

Dashboard (tableau de bord)

Un tableau de bord est un instrument de mesure de performance facilitant le pilotage proactif

d’une ou plusieurs activités dans le cadre d’une démarche de progrès. Le tableau de bord

contribue à réduire l’incertitude et facilite la prise de risque inhérente à toutes décisions.

Le tableau de bord est un instrument d’aide à la décision.

Le reporting

Le reporting est l'opération consistant, pour une entreprise, à faire rapport de son activité.

C'est la présentation périodique de rapports et bilans analytiques sur les activités et résultats

d'une organisation, d'une unité de travail ou du responsable d'une fonction, destinée à en

informer ceux chargés de les superviser en interne ou en externe, ou tout simplement

concernés par ces activités ou résultat. Les outils de reporting proposent la réalisation

de rapports selon un format prédéterminé. Les bases de données sont interrogées selon les



requêtes SQL préparées lors de l'élaboration du modèle. Le rapport peut ensuite être diffusé

sur l'Intranet, périodiquement en automatique ou ponctuellement à la demande. L'outil

d'élaboration du modèle du rapport offre bien entendu des fonctions spécifiques de calcul et

de présentation (graphiques) afin de concevoir des comptes rendus particulièrement seyants et

pertinents.

Le data mining

Le data mining est un concept né du courant de l'intelligence artificielle et qui emploie des

techniques sophistiquées pour dégager des tendances et des modèles par une analyse de

données. Le data mining est un ensemble de traitements et analyses statistiques de bases de

données permettant d´établir des relations et des comportements types. On essaye d´établir

des corrélations entre des données afin d´en tirer des renseignements, des indicateurs, des

anomalies, des correspondances, etc.

On peut dire que le data mining est l'ensemble des techniques qui permettent de transformer

les données en connaissances.

OLAP (On-Line Analytical Processing)

La finalité d'un Data Warehouse est d'obtenir des vues multidimensionnelles représentées

sous la forme d'un «cube » en trois dimensions sachant qu’une base multidimensionnelle peut

comporter de nombreuses dimensions.

Les systèmes OLAP mettent en œuvre des technologies permettant de rassembler, gérer,

traiter et présenter des données multidimensionnelles à des fins d'analyse et de décision.

Un outil OLAP est capable de fournir une information multidimensionnelle partagée pour

l'analyse rapide.

IV.4 Modélisation multidimensionnelle

La modélisation dimensionnelle structure les données d'une façon très différente de la

structure en 3FN (3ème forme normale) fréquemment utilisée par les modélisateurs des

systèmes OLTP. La modélisation dimensionnelle produit ce qu'on appelle le Modèle

dimensionnel.

IV.4.1 Dimension

Lorsqu'on fait un schéma de base de données pour un système d'information classique, on

parle en termes de tables et de relations, une table étant une représentation d'une entité et une

relation une technique pour lier ces entités. En BI, on parle en termes de Dimension et de

Faits. C'est une autre approche des données, on entend par dimensions les axes avec lesquels



on veut faire l'analyse. Il peut y avoir une dimension client, une dimension produit, une

dimension géographie (pour faire des analyses par secteur géographique).

Une dimension est tout ce qu'on utilisera pour faire nos analyses.

IV.4.2 Fait

Les faits, en complément aux dimensions, sont ce sur quoi va porter l'analyse. Ce sont des

tables qui contiennent des informations opérationnelles et qui relatent la vie de l'entreprise.

Un fait est tout ce qu'on voudra analyser.

IV.4.3 Mesure

Une mesure est un hyper cube, le plus souvent de type entier ou décimal, structuré par des

dimensions.

IV.4.4 Étoile

Une étoile est une façon de mettre en relation les dimensions et les faits dans un entrepôt de

données. Nous le verrons plus tard, mais le principe est que les dimensions sont directement

reliées à un fait (schématiquement, ça fait comme une étoile).

Figure 5. Schéma en étoile

IV.4.5 Flocon

Un autre modèle de mise en relation des dimensions et des faits dans un entrepôt de données.

Le principe étant qu'il peut exister des hiérarchies de dimensions et qu'elles sont reliées aux

faits. (Schématiquement, ça fait comme un flocon).



Figure 6. Schéma en flocon de neige

Note : les flocons et les étoiles peuvent être vus comme une manière de diviser les entrepôts

de données et les magasins de données. On peut les voir comme l'atome de l'informatique

décisionnelle: le plus petit élément avec lequel ont peut faire des analyses et avec lequel ont

peut faire des magasins de données qui, mis ensemble, forment un entrepôt de données.

V. Conclusion

Ce chapitre a présenté l’état de l’art dans le domaine de recouvrement ainsi que dans celui

des projets décisionnels. C’est ce qui nous a donné l’idée de lier ces deux domaines l’un à

l’autre grâce à une solution Business Intelligence qui va permettre d’améliorer le processus de

suivi des impayés et de faciliter la prise de décision du point de vue recouvrement. Dans le

chapitre qui suit, nous allons présenter les différentes méthodes de travail existantes dans le

lieu du stage et dégager les besoins des différents gestionnaires pour pouvoir par la suite

passer à la conception de notre solution.


30 Chapitre III : Etude de l’existant et spécification des besoins | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

Chapitre : Etude de l’existant et

spécification des besoins

I. Etude de l’existant

II. Spécification des besoins

III. Conclusion



Dans ce chapitre, nous donnons une description du fonctionnement actuel du département

des affaires juridiques et du recouvrement, par la suite nous présentons les différents besoins

fonctionnels et non fonctionnels du projet, capturés pendant la phase de l’étude de l’existant.

Nous terminons par une synthèse qui argumente le besoin pour l’application.

I. Etude de l’existant

Tout travail organisé et qui a suivi une méthodologie rationnelle doit initialement être

fondé sur l'analyse des faits, autrement dit, celui qui veut réaliser un travail pertinent doit au

premier lieu fusionner avec l'activité sujet d'optimisation, dans le but de recueillir toutes les

informations nécessaires à la réalisation de son travail et aussi pour extraire les procédures et

les traitements suivis dans l'accomplissement des tâches en question.

I.1 Contexte de l’ATB

Arab Tunisian Bank est un opérateur important dans le marché de financement en Tunisie.

Toujours fidèle à ses valeurs, l’ATB est une banque proche de ses clients. Elle a pour

principal objectif de répondre au mieux aux exigences et aux besoins de sa clientèle en

matière d’accompagnement, de réactivité, et de transparence.

L’ATB privilégie ainsi les relations durables qu’elle entretient grâce à sa capacité à être

flexible et à trouver les solutions adéquates qui facilitent la vie de ses clients. Mais ces clients

peuvent parfois devenir les acteurs conduisant la banque à sa perte si ceux-ci se transforment

en mauvais payeurs.

La gestion de la relation financière avec les clients s’avère être une fonction stratégique pour

toute entreprise.

L’ATB dispose d’un département spécialisé dans le recouvrement et les affaires juridiques, à

savoir le recouvrement des impayés financiers, des impayés commerciaux et des comptes

gelés débiteurs. Le recouvrement se fait donc à l’amiable ou par voie judiciaire.

Un décideur du département de recouvrement et des affaires juridiques peut faire recours au

système d’information de la banque pour répondre à plusieurs besoins :

Suivi des créances et des comptes gelés classés et classables.

Renseigner le tableau de bord relatif aux prévisions et aux réalisations des actions de

recouvrement.

Réceptionner les propositions de transfert à contentieux émanant des agences.



Vérification des encours et des garanties.

Toute autre tâche ou responsabilité nécessitée par les besoins du service.

I.2 Architecture fonctionnelle actuelle du système de suivi des impayés

L’ATB fonctionnait avec le système ORACLE, mais récemment ils ont été obligés de faire

migrer les données vers un nouveau système spécifique à la banque arabe intitulé

« EQUATION ». La migration des données n’est pas encore terminée, donc une partie des

données qui concernent les impayés appartient toujours à l’ancien système. Les deux

différents systèmes présentent beaucoup de différences qui se manifestent au niveau de la

nomenclature des données, de la fréquence de mise à jour et encore des SGBD.

Pour faire le suivi des impayés, le département de recouvrement et des affaires juridiques

dispose d’une interface ORACLE et d’une interface EQUATION. Les décideurs du

département fournissent leurs différents besoins au système d’information qui y répond grâce

à des requêtes SQL. Une application est déjà mise en place pour faire le suivi des impayés

financiers seulement.

Les différentes interfaces qui permettent de suivre l’état des impayés sont les suivantes :

Interface 1. Première interface Oracle

Cette interface permet d’avoir des informations globales sur les crédits et le mouvement des

comptes.



Interface 2. Deuxième interface Oracle

Cette interface permet d’avoir des informations globales sur les clients et les soldes débiteurs.

Interface 3. Interface EQUATION

Cette interface permet de consulter la situation des comptes des clients de l’ATB, leurs soldes

et les transactions effectuées.



Interface 4. Application de suivi des impayés financiers

Cette application permet de suivre l’état des impayés financiers par agence et par numéro de

compte.



Le fonctionnement actuel du système de suivi des impayés se résume par la figure qui suit :

Figure 7. Architecture fonctionnelle actuelle du système de suivi des impayés



I.3 Critique de l’existant

Face au nombre important de dossiers, les décideurs du département se trouvent face à des

conflits de gestion. Les données relatives à la créance peuvent être saisies manuellement mais

aussi importées à partir de plusieurs sources de données via des interfaces multiples. Ceci

entraine parfois des risques de redondance et de double saisie, sans oublier la perte de temps

qui en résulte.

Le suivi des impayés, des comptes gelés et des créances courantes manque de

performance, ceci est en grande partie dû à l’absence d’une vue globale sur les informations

nécessaires à la gestion du recouvrement. Les données sur les impayés et les comptes gelées

sont stockées dans des systèmes de natures différentes sous des formats différents selon des

structures différentes. Elles sont aussi hétérogènes sur le plan logique. Il faut encore noter

qu’il ya une grande dépendance vis-à-vis du système d’information. Tout ceci entraine dans

plusieurs une non cohérence des données.

Les responsables trouvent des difficultés pour dégager des analyses de l’existant, vu le

volume important et la complexité de la structure des données. Les rapports manuels qu’ils

génèrent sont pauvres en matière de statistiques descriptives telles que les graphiques.

La prise de décision est donc une action qui parait lourde.

II. Spécification des besoins

L'étude de l’existant sert généralement de point de départ pour écrire le cahier des charges.

A défaut de pré-analyse, le point de départ de la phase de définition sera constitué par les

besoins des responsables. Il est important de réaliser que l'énoncé d'un besoin ne constitue pas

un cahier des charges. Je vais donc tout d’abord présenter l’énoncé du besoin des

responsables, poursuivre avec les besoins fonctionnels et les besoins non fonctionnels de

l’application et finir avec la modélisation de ces besoins par un schéma qui illustre

l’architecture fonctionnelle cible du système de suivi des impayés.

II.1 Enoncé du besoin

Le besoin énoncé par le responsable de recouvrement est le suivant :

« Concevoir et développer une application intégrée qui communique avec un entrepôt

regroupant toutes les données relatives aux créances impayées et qui permet de suivre la

situation de ces dernières tout en générant des rapports automatiques ».



II.2 Besoins fonctionnels

Les dirigeants peuvent analyser la procédure de recouvrement pour garantir sa

performance, selon plusieurs axes (client, zone géographique, temps, secteur d’activité…) et

spécifier les causes pertinentes de non paiement.

Une des solutions est la mise en place d’un datamart qui stocke de manière cohérente le

maximum de données relatives aux impayés au fur et à mesure qu’elles se présentent pour

qu’elles soient exploitables directement, ce datamart est donc mis à jour de façon régulière en

fonction de l’évolution des données sources.

Par la suite, un tableau de bord qui se connecte à cet entrepôt de données permettra de suivre à

la trace la situation des impayés et des comptes gelés selon différents axes d’analyse et de

générer d’une façon automatique des rapports qui résument l’état des impayés.

Cette solution permet aux responsables de recouvrement d’avoir une vue globale sur les

différentes données via une interface unique pour pouvoir finalement gagner en productivité

en rationnalisant les traitements manuels et en facilitant l’accès aux informations.

Cette analyse finira par la recherche de solutions afin de prendre les mesures de protection

adéquates permettant de détecter les clients « Bons/Mauvais » payeurs et de maintenir une

bonne relation avec un bon client qui rencontre une difficulté passagère et de choisir en

fonction du profil du client, la plateforme et l’action la plus adaptée.

II.3 Besoins non fonctionnels

Les besoins non fonctionnels sont les lacunes qui peuvent empêcher l’application de

fonctionner de manière efficace et performante.

Capacité

La quantité totale des données recueillies au sein des bases de données sélectionnées

représente un volume très important. De plus le traitement de celles-ci augmentera quelque

peu ce volume initial. De ce fait, la capacité du serveur doit être suffisante afin de pouvoir

recueillir l'ensemble de ces données, permettre l'exécution du programme et la sauvegarde des

mises à jours au fil du temps.

Intégrité

A tous les niveaux de la mise en place de l'entrepôt de données, différentes erreurs devront

être traitées notamment celles-ci :

Le traitement des mauvaises données lors de l'import de données à partir des

différentes bases.



Afin d'homogénéiser le format des données recueillies, il s'avérera nécessaire

de convertir les structures bidimensionnelles en structures tridimensionnelles.

Cette démarche sera la source d'erreurs qu'il faudra prendre en compte.

L'intégrité référentielle dans les tables de base de données.

Qualité

Facilitation de l’accès aux données et de la diffusion de l’information.

fiabilité et traçabilité des données.

Interaction homme machine la plus intuitive possible.

Simplicité

Vu que parmi les utilisateurs de l’application, il existe ceux qui n’ont pas nécessairement de

grandes connaissances dans le domaine de l’informatique, les fonctionnalités de la solution

doivent être compréhensibles et simples à manipuler. En effet, la navigation à travers les

différentes rubriques doit être conçue de manière à ce que l’utilisateur s’y retrouve aisément ;

celui-ci doit en fait se sentir maître de la situation à tout moment.

Performance

L’application doit répondre à toutes les exigences des utilisateurs d’une manière optimale. La

performance de l'application se traduit par un temps d’accès allégé aux différentes

fonctionnalités, un temps d'accès aux données acceptables vu la manipulation d'un entrepôt de

données relativement important.

Fiabilité

Il faut garantir la qualité du contenu et la pertinence des informations.

L’ergonomie

La première chose qui attire l’attention des utilisateurs c’est l’ergonomie et la facilité

d'utilisation, pour cela une attention particulière doit être donnée à ce besoin.

II.4 Architecture fonctionnelle cible du système de suivi des impayés

Le département de recouvrement et des affaires juridiques a besoin d’un système d’aide à

la décision qui lui permet de suivre l’état des impayés et d’avoir une vue globale sur toutes les

données via une interface unique.

L’architecture fonctionnelle cible du système de suivi des impayés est résumé par la figure

qui suit :



Figure 8. Architecture fonctionnelle cible du système de suivi des impayés

Ce nouveau système permet de recueillir toutes les données relatives aux impayés provenant

de sources différentes et de les stocker dans un entrepôt (datamart impayés) grâce à des ETL.

Les données seront par la suite chargées dans « qlikview » (voir Annexe B) afin de pouvoir

finalement créer des bilans sur les impayés pour des fins d’analyse et de reporting.

III. Conclusion

Tout au long de ce chapitre, nous avons étudié la situation actuelle du système de suivi des

impayés afin de dégager les problèmes et de proposer de meilleurs solutions. C’est ce qui

nous a aidés à identifier les besoins fonctionnels et non fonctionnels de l’application, ce qui

va simplifier le travail ultérieur de conception.


40 Chapitre IV : Conception | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

Chapitre : Conception

I. Etapes de la phase conceptuelle

II. Le tableau de bord

III. Conclusion



Le besoin étant maintenant connu, il faut commencer par construire le cœur de tout

système de reporting, le Datamart.

Pour le faire il faut :

Faire une analyse multidimensionnelle afin d’identifier les différentes dimensions et

mesures dans le Datamart.

Modéliser le Datamart grâce à un schéma de modélisation de datawarehouse

(Datawarehousing).

Etudier les sources de données qui vont alimenter le Datamart.

Etablir un mapping entre les données sources et les champs du Datamart.

I. Etapes de la phase conceptuelle

I.1 Détermination des objectifs et des scénarios d’analyse

Les objectifs doivent être choisis et non imposés, choisis directement par les décideurs

eux-mêmes sous forme de besoin exprimé. C’est à nous, maîtres d’œuvres, de formaliser ces

objectifs et de les énoncer sous forme d’objectifs directement réalisables.

Un bon objectif est un objectif :

Mesurable : L'objectif s'exprime en fonction d'une unité de mesure.

Borné : L'objectif est impérativement défini dans une dimension de temps.

Réaliste : La Méthode pour l'atteindre est tout à fait plausible.

Accessible : Les moyens sont disponibles, les risques limités.

Fédérateur : L'objectif recueille l'adhésion de la majorité.

Constructif : L'objectif contribue à la démarche de progrès.

L’objectif est concrétisé par des scénarios d’analyse.

Dans notre cas, l’objectif est d’analyser le volume global des impayés.

Nous avons choisi comme scénarios d’analyse de faire :

Le suivi du volume global des impayés

Le suivi des encours

La classification des engagements

Le suivi des détails de l’encours par échéances

Traitement des guaranties

Les différents objectifs et scénarios d’analyse sont résumés dans le tableau qui suit :



I.2 Choix des mesures ou des indicateurs

Un indicateur clé de performance ou « key performance indicator » est une mesure ou un

ensemble de mesures braquées sur un aspect critique de la performance globale de

l’organisation.

Ces indicateurs sont dégagés lors de la phase de capture des besoins exprimés par les

décideurs.

Les mesures retenues dans notre table de faits sont :

Mesure Libellé

Montant_impayé Montant de l’impayé

Imp_principal Impayé en principal

Imp_intérêt Impayé en intérêt

Encours Encours total

Encours_principal Encours en principal

Encours_interet Encours en intérêt

Remboursement_principal Remboursement en principal

Remboursement_interet Remboursement en intérêt

Solde_compte Solde du compte

Tableau 3. Mesures retenues

Tableau 2. Objectifs et scénarios d'analyse

Thème

d’analyse Objectif Scénarios d’analyse Indicateurs Axes d’analyse

Impayés

-Analyser

le volume

global

d’impayés.

-Suivi du volume

global des impayés.

-Suivi des encours.

-Classification des

engagements.

-Détails de l’encours

par échéances.

-Traitement des

garanties.

-Nombre

d’impayés.

-Montants des

impayés.

-Détermination des

encours.

-Client

-Compte

-Décision

-Agence

-Zone

-Secteur

-Type crédit

-Date

-Echéances

-Nature du

compte

-Classe

-Sexe



I.3 Choix des dimensions

Une dimension correspond à un axe d’analyse de la problématique du projet, elle est

nécessairement un facteur dont dépend l’aspect que l’objectif du projet essaye de mesurer.

A chaque dimension est attribuée une table. Il existe autant de tables dimensions que de

dimensions. Chaque table de dimension contient les attributs de la dimension en question plus

une clé primaire indépendante de ces attributs.

Les axes d’analyse que nous allons insérer dans notre modèle sont :

I.4 La table de faits

Les tables de faits représentent des associations dont l’existence d’une occurrence dépend

de l’existence des occurrences correspondantes dans les tables dimensionnelles, c’est-à-dire la

table de fait contient l’ensemble des mesures correspondant aux informations de l’activité à

analyser.

La table de fait dans notre cas se présente comme suit :

Figure 9. Table de faits fact_impaye

fact_impayé

num_cpte

id_tps

n°effet

nom_recouvreur

montant_impayé

imp_principal

imp_interet

encours

encours_principal

encours_interet

remboursement_principal

remboursement_interet

solde_compte

...

varchar(15)

integer

numeric

varchar(30)

numeric

numeric

numeric

numeric

numeric

numeric

numeric

numeric

numeric

<pk,fk1>

<pk,fk2>

<pk,fk3>

<pk,fk4>

Dimension Libellé

Dim_temps Dimension temps

Dim_cpte_clt Dimension compte client

Dim_client Dimension client

Dim_dossier Dimension dossier

Dim_garantie Dimension garantie

Dim_recouvreur Dimension recouvreur

Dim_zone Dimension zone

Tableau 4. Dimensions retenues

Clés étrangères vers les

tables de dimensions

Mesures



I.5 Modélisation du Datamart IMPAYES

Il faut savoir que la modélisation en flocon de neige existe pour des raisons de

performance. En effet, des dimensions de plusieurs millions de lignes peuvent poser des

problèmes de lenteur lors de l’exploitation des données. Le principe de la modélisation en

flocon de neige est de créer des hiérarchies de dimensions, de telle manière à avoir moins de

lignes par dimensions.

De plus, le schéma en flocons de neige est approprié aux dimensions dont les niveaux sont

reliés par des relations n à n et 1 à n. Par ailleurs, le schéma en flocons de neige devient

obligatoire pour une relation dimension-fait de n à n.

Dans notre cas par exemple, un client peut avoir un ou plusieurs comptes, un dossier peut

contenir une ou plusieurs garanties. Il est donc envisageable de recourir à une modélisation en

flocon de neige.

En termes Merise, le MPD est lui seul utilisé pour modéliser les datawarehouses.

Nous avons réalisé les schémas de modélisation avec le logiciel PowerAMC. (Voir Annexe B)

Voici finalement notre schéma conceptuel du Datamart IMPAYES :

Figure 10. Datamart IMPAYES

dim_cpte_clt

num_cpte

num_idt

type_idt

nbre_sign

date_relevé

matricule_employé

compte_cloture

compte_gelé

date_gel

date_récupération

date_ouverture

dat_derniere_op

...

varchar(15)

varchar(15)

numeric

numeric

date

numeric

numeric

numeric

date

date

date

date

<pk>

<fk>

<fk>

dim_dossier

n°effet

type_effet

montant_effet

date_dec

premiere_ech

derniere_ech

rate

marge

type_crdt

...

numeric

char(1)

numeric

date

date

date

numeric

numeric

char(3)

<pk>

dim_zone

IDZONE

nom_recouvreur

NOMZONE

integer

varchar(30)

varchar(20)

<pk>

<fk>

dim_temps

id_tps

jour

mois

trimestre

année

...

integer

integer

integer

integer

integer

<pk>

fact_impayé

num_cpte

id_tps

n°effet

nom_recouvreur

montant_impayé

imp_principal

imp_interet

encours

encours_principal

encours_interet

remboursement_principal

remboursement_interet

solde_compte

...

varchar(15)

integer

numeric

varchar(30)

numeric

numeric

numeric

numeric

numeric

numeric

numeric

numeric

numeric

<pk,fk1>

<pk,fk2>

<pk,fk3>

<pk,fk4>

dim_garantie

n°effet

code_gar

état_gar

montant_gar

date_évaluation

...

numeric

integer

integer

numeric

date

<fk>

dim_client

type_idt

num_idt

nom_clt

prénom_clt

date_naissance

adresse

num_tel

num_fax

activité_atb

activité_bct

indicateur_résident

nom_abrégé

code_nationalité

forme_juridique

numeric

varchar(15)

varchar(30)

varchar(30)

date

varchar(75)

numeric

numeric

numeric

numeric

numeric

varchar(10)

numeric

numeric

<pk>

<pk>

dim_recouvreur

nom_recouvreur varchar(30) <pk>



I.6 Etude des données sources

Nous avons réorganisé les champs de chaque table source par groupe thématique.

Le dictionnaire des données complet se trouve dans l’Annexe A.

Table client

C’est la table qui contient les informations sociodémographiques sur la clientèle de l’ATB

(particuliers et entreprises). Elle se situe au niveau de la base « Centrale 2 ».

Groupe thématique Information

Informations client Identifiant, nom, prénom, date de naissance

Coordonnées client Nom, prénom, adresse, téléphone, fax,

courrier

Informations compte Numéro du compte, agence, type de compte

Informations socioprofessionnelles Secteur d’activité, nationalité, indicateur

résident

Tableau 5. Table client

Table compte client

C’est la table qui contient les informations sur les comptes de la clientèle de l’ATB. Elle se

situe au niveau de la base « CENTRALE 2 ».


Informations compte Numéro de compte, agence, type de compte,

état compte, devise

Opérations sur le compte Date d’ouverture, date relevé, date gel, date

récupération, date de dernière opération

Informations propriétaire Nombre de signataires, coordonnées client

Tableau 6. Table compte client

Table garantie

C’est la table qui contient les informations sur les garantie détenues sur la clientèle de l’ATB.

Elle se situe au niveau de la base « CREDIT ».


Données garantie Numéro de décision, code garantie

Évaluation garantie État garantie, montant évalué, date

d’évaluation

Tableau 7. Table garantie



Table impayé financier

C’est la table qui contient les informations sur les crédits accordés à la clientèle de l’ATB et

qui n’ont pas été remboursés. Elle se situe au niveau du système Equation.


Informations compte Numéro de compte, agence, type de compte

Informations crédit Référence crédit, type de crédit, code

engagement

Payement crédit Date échéance, montant payé, montant

impayé, encours

Tableau 8. Table impayé finanicer

Table impayé commercial

C’est la table qui contient les informations sur les effets de commerces accordés à la clientèle

de l’ATB et qui n’ont pas été remboursés à l’échéance. Elle se situe au niveau de la base

« Centrale 2 ».

Tableau 9. Table impayé commercial

Table encours crédit

C’est la table qui contient les informations sur les créances, le montant remboursé, le montant

impayé et l’encours. Elle se situe au niveau du système Equation.


Données crédit Montant crédit, type crédit, code engagement,

devise, rate, marge

Décision Numéro décision, date décision, première et

dernière échéance

Informations sur l’impayé Impayé en principal, impayé en intérêt, date

entrée en impayé

Informations sur le remboursement Remboursement en principal, remboursement

en intérêt

Informations sur l’encours Encours en principal, encours en intérêt

Tableau 10. Table encours credit


Données comptes Numéro compte, agence, type de compte

Données remboursement Date échéance, date remboursement, date

rejet, code rejet

Données client tiré Nom tiré, compte tiré.



Table cumul crédit mensuel

C’est la table qui contient le montant de crédit cumulé mensuellement sur les comptes de la

clientèle de l’ATB. Elle se situe au niveau de la base « Centrale2 ».


Informations compte Numéro de compte

Données cumul Cumul crédit par mois

Tableau 11. Table cumul crédit mensuel

Table cumul crédit quotidien

C’est la table qui contient le montant de crédit cumulé quotidiennement sur les comptes de la

clientèle de l’ATB. Elle se situe au niveau de la base « Centrale2 ».



Données cumul Mois actuel, total mvt crédit du mois

Tableau 12. Table cumul crédit quotidien

Table agios débit

C’est la table qui contient le montant des agios sur les comptes de la clientèle de l’ATB. Elle

se situe au niveau de la base « Centrale2 ».



Données agios Agios trimestriels de l’année actuelle, agios

trimestriels de l’année précédente

Tableau 13. Table agios débit

Table solde du compte

C’est la table qui donne le solde des comptes de la clientèle de l’ATB. Elle se situe au niveau

de la base « Centrale2 ».


Informations compte Numéro de compte, solde du compte

Tableau 14. Table solde du compte



Table liste chef de zone

C’est la table qui donne la répartition des responsables selon les agences. Elle est stockée dans

un fichier Excel.


Informations agence Code agence, nom agence, zone agence

Informations responsable Responsable garantie, responsable

contentieux, chef de zone

Tableau 15. Table liste chef de zone

I.7 Le mapping

L’opération de mapping consiste à faire la correspondance entre les données sources et les

champs du Datamart afin de charger correctement ce dernier. C’est l’étape précédente (étude

des données sources) qui nous permettra de mener à bien cette étape.

Table dim_cpte_clt

Champ Datamart Champ source Table source Transformation

Num_cpte

CODSGE Cptclt

Concaténation CPTGNL Cptclt

CPRPRT Cptclt

Num_idt NUMIDT Client One to one

Type_idt TYPIDT Client One to one

Nbre_sign NBRSGN Client One to one

Date_relevé DATREL Cptclt One to one

Matricule_employé MATEMP Cptclt One to one

Compte_cloture CLTTRS Cptclt One to one

Compte_gelé CPTGEL Cptclt One to one

Date_gel DATGEL Cptclt One to one

Date_récupération DATREC Cptclt One to one

Date_ouverture DATEOUV Cptclt One to one

Dat_dernière_op DATDOP Cptclt One to one

Tableau 16. Mapping de la table dim_cpte_clt



Table dim_client

Champ datamart Champ source Table source Transformation

Type_idt TYPIDT Client One to one

Num_idt NUMIDT Client One to one

Nom_clt NOMCLT Client One to one

Prénom_clt PRNCLT Client One to one

Date_naissance DATNAI Client One to one

Adresse ADRDOM Client One to one

Num_tel NUMTEL Client One to one

Num_fax NUMFAX Client One to one

Activité_atb ACTATB Client One to one

Activité_bct ACTBCT Client One to one

Indicateur_résident INDRES Client One to one

Nom_abrégé NOMABR Client One to one

Code_nationalité CNATIO Client One to one

Forme_juridique FRMJUR Client One to one

Tableau 17. Mapping de la table dim_client

Table dim_dossier

Champ Datamart Champ source Table source Transformation Description

N°effet

Y04DLR y04pf

Dérivé

Si type_effet = « F » alors

N°effet =Y01DLR

Si «Type_effet » = « C »

alors N°effet = NUMEFF

Si « type_effet »

= « G » alors N°effet =num_cpte

NUMEFF Effimpm

Type_effet - - Dérivé « F » si financier

« C » si commercial « G » si compte gelé

Montant_effet Y01DLA2 y01pf

One to one Y01DLA2 si « F »

MNTEFF si « C » Solde_cpte si « G » MNTEFF Effimpm

Date_dec Y01CTTRD y01pf One to one

Seulement si

type_effet = « F »

Premiere_ech Y01FDTE y01pf One to one

Derniere_ech Y01LDTE y01pf One to one

Rate Y01RAT y01pf One to one

Marge Y01MGN y01pf One to one

Type_crdt Y04DLP y04pf One to one

Tableau 18. Mapping de la table dim_dossier



Table dim_garantie

Champ Datamart Champ source Table source Transformation

N°effet Y04DLR y04pf -

Code_gar CODGAR Decgar One to one

Etat_gar ETAGAR Decgar One to one

Montant_gar MNTEVA Decgar One to one

Date_évaluation DATEVA Decgar One to one

Tableau 19. Mapping de la table dim_garantie

Table dim_recouvreur


Nom_recouvreur Garantie Liste chef de zone One to one

Tableau 20. Mapping de la table dim_recouvreur

Table dim_zone


Id_zone CODSGE Cptclt One to one

Nom_recouvreur Garantie Liste chef de zone One to one

Nom_zone Zone Liste chef de zone One to one

Resp_zone Chef de zone Liste chef de zone One to one

Tableau 21. Mapping de la table dim_zone

II. Le tableau de bord

Le processus de prise de la décision doit répondre au principe de l’intelligence collective et

doit impliquer tous les acteurs pour qu’ils soient motivés et par conséquent s’investissent dans

la réalisation des objectifs souhaités.

Pour un partage de la connaissance et une prise de décision décentralisée, nous avons eu

l’idée de créer des tableaux de bord destinés au personnel du département de recouvrement et

des affaires juridiques participant dans le processus de recouvrement des créances impayées.

Ces tableaux seront alimentés par le Datamart préalablement conçu.

Des schémas et des rapports seront créés. Cette opération permet à chaque membre de

contrôler sa performance et de l’améliorer, ainsi que bien répartir son travail et partager

implicitement la connaissance des problèmes et la conscience d’éventuels retards. Cela

permettra aux membres de bien apprécier les problèmes rencontrés, de participer à la prise de

la décision ainsi que de s’investir dans d’éventuels plans d’ajustement.



Nous avons donc choisi de concevoir des rapports basés sur le type de l’impayé.

II.1 Rapports d’analyse des impayés financiers

II.1.1 Schéma

Figure 11. Rapports d'analyse des impayés financiers

Ce schéma montre les différents axes d’analyse sur lesquels sont basés les rapports

d’analyse des impayés financiers.

rapports d'analyse

des impayés

finanicers

agence

Zone

Temps

Age

Recou-vreur

compte Type crédit

Client

Classe

Sexe

Déci-sion



II.1.2 Table des dimensions

Dimension Hiérarchie Niveau Table source

Agence Agence Agence Cptclt

Zone Zone Zone Cptclt

Temps

H1

Mois

-

Trimestre

Semestre

Année

H2

Semaine

Mois

Trimestre

Age Age

Age inférieur à 30

Client Age entre 30 et 40

Age entre 40 et 50

Age entre 50 et 60

Age supérieur à 60

Recouvreur Recouvreur Recouvreur Liste chef de zone

Compte Compte Compte Cptclt

Type credit Type credit Type credit Y04PF

Client Client Client Client

Classe Classe Classe -

Sexe Sexe Sexe Client

Décison Décison Décision Y04PF

Tableau 22. Table des dimensions des impayés financiers

Ce tableau reprend les différents axes du schéma précédant et les met en dimensions

relatives aux impayés financiers.

Ainsi nous avons pu dégager les différentes hiérarchies et leurs niveaux respectifs.



II.1.3 Table des agrégations

Nom Statistique Description

TOTAL_IMP_FIN_SEMAINE Sum Montant total des impayés financier par

semaine

TOTAL_IMP__FIN_MOIS Sum Montant total des impayés financiers

par mois

TOTAL_IMP__FIN_TRIM Sum Montanttotal des impayés financiers par

trimestre

TOTAL_IMP__FIN_SEM Sum Montant total des impayés financiers

par semestre

TOTAL_IMP_FIN_ANNEE Sum Montant total des impayés financiers

par année

NBRE_IMP_FIN Count Nombre total des impayés financiers

MOY_IMP_FIN_SEMAINE AVG Moyenne des impayés financiers par

semaine

MOY_IMP_FIN_MOIS AVG Moyenne des impayés financiers par

mois

MOY_IMP_FIN_TRIMESTRE AVG Moyenne des impayés financiers par

trimestre

MOY_IMP_FIN_SEMESTRE AVG Moyenne des impayés financiers par

semester

MOY_IMP_FIN_ANNEE AVG Moyenne des impayés financiers par

année

TAUX_RECUP_FIN AVG Taux de récupération moyen

TOTAL_PROV_FIN SUM Provisions constituées totales

Tableau 23. Table des agrégations des impayés financiers

La table des agrégations des impayés financiers donne les différentes statistiques que l’on

peut calculer pour pouvoir juger de la situation des impayés financiers.



II.2 Rapport d’analyse des impayés commerciaux

II.2.1 Schéma

Figure 12. Rapports d'analyse des impayés commerciaux


d’analyse des impayés commerciaux.

rapports d'analyse des

impayés commerciaux

Agence

Zone

Temps

Age

Recou-vreur

Compte

Client

Classe

Sexe

Effet







Temps

H1

Mois

-

Trimestre

Semestre

Année

H2

Semaine

Mois

Trimestre

Age Age



Age entre 40 et 50

Age entre 50 et 60







Effet Effet Effet Effimpm

Tableau 24. Table des dimensions des impayés commerciaux


relatives aux impayés commerciaux.






TOTAL_IMP_COM_SEMAINE SUM Montant total des impayés

commerciaux par semaine

TOTAL_IMP_COM_MOIS SUM Montant total des impayés

commerciaux par mois

TOTAL_IMP_COM_TRIM SUM Montant total des impayés

commerciaux par trimestre

TOTAL_IMP_COM_SEM SUM Montant total des impayés

commerciaux par semestre

TOTAL_IMP_COM_ANNEE SUM Montant total des impayés

commerciaux par année

NBRE_IMP_COM COUNT Nombre total des impayés

commerciaux

MOY_IMP_COM_SEMAINE AVG Moyenne des impayés commerciaux

par semaine

MOY_IMP_COM_MOIS AVG Moyenne des impayés commerciaux

par mois

MOY_IMP_COM_TRIMESTRE AVG Moyenne des impayés commerciaux

par trimestre

MOY_IMP_COM_SEMESTRE AVG Moyenne des impayés commerciaux

par semester

MOY_IMP_COM_ANNEE AVG Moyenne des impayés commerciaux

par année

TAUX_RECUP_COM AVG Taux de récupération moyen

TOTAL_PROV_COM SUM Provisions constituées totales

Tableau 25. Table des agrégations des impayés commerciaux

La table des agrégations des impayés commerciaux donne les différentes statistiques que

l’on peut calculer pour pouvoir juger de la situation des impayés commerciaux.



II.3 Rapport d’analyse des comptes gelés

II.3.1 Schéma

Figure 13. Rapports d'analyse des comptes gelés


d’analyse des comptes gelés.

rapports d'analyse des comptes gelés

Agence

Zone

Temps

Age

Recou-vreur

Compte

Client

Classe

Sexe







Temps

H1

Mois

-

Trimestre

Semestre

Année

H2

Semaine

Mois

Trimestre

Age Age



Age entre 40 et 50

Age entre 50 et 60







Tableau 26. Table des dimensions des comptes gelés


relatives aux comptes gelés.






TOTAL_DEBIT_SEMAINE SUM Débit total par semaine

TOTAL_DEBIT_MOIS SUM Débit total par mois

TOTAL_DEBIT_TRIM SUM Débit total par trimestre

TOTAL_DEBIT_SEMESTRE SUM Débit total par semestre

TOTAL_DEBIT_ANNEE SUM Débit total par année

NBRE_COMPTES_GELES COUNT Nombre de compte gelés

MOY_DEBIT_SEMAINE AVG Débit moyen par semaine

MOY_DEBIT_MOIS AVG Débit mensuel moyen

MOY_DEBIT_TRIM AVG Débit trimestriel moyen

MOY_DEBIT_SEM AVG Débit semestriel moyen

MOY_DEBIT_ANNEE AVG Débit annuel moyen

TAUX_RECUP_CG AVG Taux de récupération sur les

comptes gelés

TOTAL_PROV_CG SUM Provisions constituées sue

les comptes gelés

Tableau 27. Table des agrégations des comptes gelés

La table des agrégations des comptes gelés donne les différentes statistiques que l’on peut

calculer pour pouvoir juger de la situation des comptes gelés.

III. Conclusion

Dans ce chapitre, nous avons présenté l’architecture globale de notre système décisionnel.

Nous avons développé en premier lieu les différentes étapes de la phase conceptuelle.

Nous avons donné en second lieu la conception générale de la solution à travers des schémas

explicatifs pour chaque type d’impayé, la conception a été détaillée aux tables de dimensions

et aux tables des agrégations

Après avoir défini, donné et expliqué la conception du système de suivi des impayés, nous

allons expliquer, dans le prochain chapitre, la réalisation de notre solution en présentant

l’environnement et les outils de travail ainsi que quelques interfaces homme-machine du

tableau de bord.


60 Chapitre V : Réalisation | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

Chapitre : Réalisation

I. Environnement et outils de travail

II. Validation et expérimentation

III. Conclusion



Dans le chapitre présent, nous nous intéressons à la réalisation du tableau de bord, dans

lequel, un paragraphe est dédié à la présentation de l’environnement logiciel et matériel grâce

auxquels nous avons pu mettre en place cette solution logicielle et un autre paragraphe est

consacré à la validation et l’expérimentation de notre solution à travers la présentation de

quelques interfaces homme-machine. A la fin de ce chapitre, nous donnons le chronogramme

prévisionnel des tâches du projet.

I. Environnement et outils de travail

Nous présentons, dans cette section, l'environnement matériel et logiciel utilisé pour le

développement de la solution.

I.1 Environnement matériel

Durant le stage, nous avons réalisé notre projet en utilisant un ordinateur portable Dell

INSPIRON N5110 dont la configuration est décrite ci-dessous :

RAM : 4Go

Disque Dur : 500Go

Processeur : Intel(R) Core(TM) i3-2310M CPU @ 2.10Ghz

I.2 Environnement logiciel

Durant la phase de développement, nous avons utilisé l'environnement logiciel suivant :

I.2.1 Outils de conception MERISE : Sybase Power AMC 15.1

Power AMC est un logiciel de modélisation. Il permet de modéliser les traitements

informatiques et leurs bases de données associées. Créé par SDP sous le nom

AMC*Designor, racheté par Powersoft, ce logiciel est produit par Sybase depuis le rachat par

cet éditeur en 1995. Hors de France, la version internationale est commercialisée par Sybase

sous la marque PowerDesigner. PowerAMC supporte différents types de modèles de bases de

données.

I.2.2 SGBD : Oracle10g

Pour le stockage du « datamart » on a utilisé Oracle 10g comme SGBD vu qu’il est un

système de gestion de base de données relationnelle et objet utilisé par l’ATB, de plus ce

SGBD présente une richesse fonctionnelle importante.



I.2.3 Outil décisionnel : Qlikview 11

QlikView est totalement différent des logiciels traditionnels de Business Intelligence. Il est

simple d'utilisation et met l'utilisateur final en situation de contrôle total de ses analyses. En

seulement quelques clics, QlikView nous a permis de consolider, chercher, visualiser et

analyser toutes nos sources de données pour une vue sans précédent sur notre activité.

II. Validation et expérimentation

Nous arrivons maintenant à la phase validation et expérimentation de notre système. Nous

avons déjà décrit toutes les étapes de conception, ce qui engendre la possibilité de définir une

architecture à notre outil d’aide à la décision.

II.1 Création du Datamart

Power Amc Designer 15.1 nous a permis de générer automatiquement les différents scripts

de création de notre Datamart « IMPAYES ».

Nous prenons comme exemple ce script, qui nous a permis de créer la table de faits

« fact_impaye ».

Interface 5. Script SQL pour la création de la table FACT_IMPAYE



II.2 Chargement des données dans Qlikview

Interface 6. Visionneur de tables

Cette interface permet de visionner les tables de note datamart « IMPAYES ».

Une fois implémenté dans l’outil décisionnel, il faut alimenter notre modèle de données.

Nous avons validé et expérimenté notre application à travers un jeu de données relatif aux

impayés qu’on a déjà construit grâce à des fichiers Excel dont chacun contient les différentes

colonnes de chaque table. Enfin, ces données sont chargées dans Qlikview grâce au script qui

suit :



Interface 7. Script pour le chargement des données dans Qlikview

II.3 Interfaces homme machine

Une fois les données sont chargées, il faut passer au vif du tableau de bord.

Grâce aux scénarios d’analyse qu’on a déjà dégagés lors de la phase de la conception, nous

allons pouvoir concevoir notre tableau de bord. Les différentes interfaces du tableau de bord

sont données dans la suite.



II.3.1 Ecran d’accueil

A l’ouverture de l’application, l’utilisateur reçoit une interface d’accueil qui contient le nom

de la société « ATB », le nom du département « DCAJR », ainsi que celui de l’application

« SUIVI DES CILENTS EN SITUATION DE RECOUVREMENT ».

Interface 8. Ecran d'accueil



II.3.2 Ecran de la situation générale des impayés

En cliquant sur l’onglet situation globale, une interface décrivant la situation globale des

impayés s’affiche. Elle contient les analyses relatives à l’état global des impayés.

Interface 9. Ecran de la situation générale

Comme nous le voyons, l’utilisateur peut choisir ses axes d’analyse grâce aux options qui se

présentent des cotés gauche et droit de l’écran. En haut, l’axe temps est hiérarchisé sur

plusieurs niveaux : année, trimestre, mois.

L’utilisateur peut sélectionner un ou plusieurs axes. S’il ne sélectionne aucun axe, les résultats

qui s’affichent sont relatifs à toute la banque. Il faut noter que si l’utilisateur choisir l’axe

« zone », les agences appartenant à cette même zone seront automatiquement sélectionnées.

La jauge donne le nombre de dossiers traités par les recouvreurs. Dans notre cas, environ la

moitié des dossiers a été traitée.

La pyramide inversée donne la répartition des dossiers par classe, dans notre cas, 46 dossiers

font partie de la classe 2, 50 dossiers font partie de la classe 3 et 8 dossiers font partie de la

classe 4.

Le tableau en haut de l’écran résume la situation générale des impayés par zone, ses colonnes

contiennent le total des dossiers en situation de recouvrement, le nombre de dossiers traités, le



volume des impayés c’est-à-dire leur montant total, et finalement le volume remboursé.

Les autres barres donnent le pourcentage de remboursement et l’état d’évolution des dossiers

par agence.

On peut focaliser sur un type de créance en choisissant une des options « commercial,

financier, compte gelé ». Ainsi on pourra générer les rapports relatifs à chaque type d’impayé.

Le camembert donnant la répartition des dossiers par type de créance, montre que la plupart

des impayés sont des impayés financiers, c’est-à-dire des crédits. C’est pour cela que nous

avons généré d’autres rapports spécifiques aux crédits et qui pourront nous renseigner sur

l’état des impayés financiers. Ces rapports se situent au niveau de l’onglet CREDITS.

II.3.3 Ecran de la situation des impayés financiers

Comme nous l’avons déjà remarqué, les impayés sont en grandes partie dus à des effets

financiers, on a donc choisi de se focaliser sur ce type de créance afin de pouvoir faciliter

l’analyse pour le décideur. En cliquant sur l’onglet « CREDITS » nous obtenons les rapports

relatifs aux crédits grâce à l’interface suivante.

Interface 10. Ecran de la situation des crédits

Comme nous le remarquons sur cet écran, de nouvelles dimensions sont mises à la disposition

du décideur. Ce sont les dimensions que nous avons préalablement fixées lors de la phase de

conception.



Un histogramme donne l’évolution du nombre de dossiers traités, c’est-à-dire le nombre de

dossiers traités quotidiennement par les recouvreurs.

Un tableau renseigne sur quelques statistiques générales qui concernent les types de crédits,

par exemple le total des dossiers, le nombre de dossiers traités, le volume d’impayés relatifs à

chaque type de crédit et le volume remboursé.

Une autre pyramide inversée donne la répartition des impayés financiers par classe, c’est-à-

dire le nombre de dossiers en situation de recouvrement dans chaque classe.

Un histogramme empilé donne la répartition des différents types de crédit par classe, nous

avons sélectionné dans notre cas tous les types de crédit.

II.4 Chronogramme

Par souci d’organisation, et afin de mener à bien ce projet, nous avons établi un

chronogramme détaillé des différentes tâches réalisées :

Etape 1 : Familiarisation avec le métier de recouvrement

Etape 2 : Etude de l’existant

Etape 3 : Etude et analyse des données sources

Etape 4 : Détermination des objectifs

Etape 5 : Conception du modèle de données

Etape 6 : Génération de l’application

Rédaction du rapport.

Février Mars Avril Mai

S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4

Etape 1

Etape 2

Etape 3

Etape 4

Etape 5

Etape 6

Rédaction du rapport

Tableau 28. Chronogramme de la planification des tâches du projet



III. Conclusion

Dans ce chapitre, nous avons spécifié l’environnement logiciel et matériel avec lequel

nous avons réalisé notre projet, ainsi que les outils et les technologies que nous avons utilisés.

Nous avons par la suite illustré l’utilisation de l’application en ce qui concerne la situation

globale des impayés et plus précisément celle des crédits, par des interfaces graphiques de

l’application. Finalement, nous avons donné le chronogramme des tâches du projet.


70 Conclusion générale et perspectives | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

Conclusion générale et perspectives

Nous nous sommes intéressés au cours de ce travail à la conception et à la réalisation

d’une application dédiée au département des affaires juridiques et du recouvrement qui

permet de suivre l’état des impayés et des comptes gelés grâce à un système décisionnel. Ce

dernier ne se conçoit pas sans l’intermédiaire d’un entrepôt de données qui regroupe les

différents types d’impayés ainsi que les informations qui leurs sont relatives, c’est pour cette

raison que nous avons recouru aux bases de données décisionnelles.

En termes de réalisation, nous avons répondu amplement aux objectifs établis par

l’entreprise malgré les difficultés rencontrées qui touchent principalement le plan technique.

Une de ces difficultés, qui était la plus ardue, concerne la compréhension de la structure des

sources de données. En effet, nous avons dû surmonter cette structure complexe composée de

plusieurs tables, chacune pouvant provenir de systèmes différents et comporter plusieurs

dizaines de champs. La documentation sur la structure de ces sources de données étant rare,

voire indisponible, il nous a fallu en conséquence un grand temps pour comprendre la relation

entre les tables ainsi que la signification de chaque attribut.

Au cours du développement de cette solution, nous avons détaillé en premier lieu les

besoins de l’application grâce à des interviews avec les décideurs du département.

Puis nous nous sommes tournés en second lieu à concevoir le modèle de données relatif à

notre Datamart « IMPAYES » de sorte que ce dernier réponde au mieux aux besoins des

différents responsables.

En dernier lieu, nous avons mis en place un tableau de bord qui contient les indicateurs de

suivi des clients en situation de recouvrement et qui contribue à minimiser les efforts fournis

par les décideurs dans le processus de prise de décision.

C’est ainsi que nous avons pu mener un stage dans les bonnes pratiques du métier de

recouvrement. Le stage a été bénéfique sur le plan technique vu que nous avons pu maitriser

la chaîne de valeur quasi-entière d’un projet BI en utilisant divers outils.


71 Conclusion générale et perspectives | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

Ce projet est l’aboutissement d’efforts multiples réalisés au sein de l’ATB. Ce travail,

accompli en collaboration avec les membres de l’équipe de recouvrement, nous a été d'une

grande utilité en termes de savoir-faire et d'un grand intérêt en apport de connaissances utiles.

C’est ainsi que nous avons pu mettre en pratique les différentes connaissances techniques,

jusqu’alors restées théoriques, et pu nous projeter dans le monde réel des entreprises et dans le

milieu professionnel avec tout ce qu’il implique en termes de discipline, de responsabilité et

de travail en équipe.

En guise de perspectives, notre solution a l’avantage d’être ouverte et extensible. Nous

pouvons ainsi envisager un système de gestion capable d’automatiser la gestion du Workflow

de recouvrement avec une réallocation automatique, à jour et optimisée des dossiers, cette

extension inclut beaucoup d’autres utilisateurs tels que les sociétés de recouvrement, les

avocats, les huissiers, la division des affaires juridiques, etc.

Une deuxième amélioration possible est l’intégration du système décisionnel avec le système

d’information de la banque, qui en contrepartie pourront faire les ETL pour l’alimentation

régulière de notre Datamart que nous n’avons pas pu achever faute de temps.

Pour conclure, l’informatique décisionnelle est un domaine très large et très prometteur

avec plusieurs champs d’application, et le fait d’être ingénieur spécialiste dans ce domaine,

c’est avoir le sens d’analyse, de conception et d’organisation, et c’est aussi avoir le sens

d’engagement envers la communauté et assumer toutes les responsabilités qui lui ont été

attribuées vu l’importance cruciale de cette discipline pour la stratégie de l’organisme.

Il semble alors intéressant de mettre en évidence que choisir cette vocation et devenir

ingénieur en décisionnel est une bonne chose. Mais ce qui est meilleur, c’est d’user de tout

son savoir-faire dans ce domaine pour une bonne cause qui est d’augmenter la qualité des

services offerts par l’administration Tunisienne pour assurer une fluidité des processus

administratifs de la finance publique et ainsi satisfaire au mieux les besoins des citoyens au

matière d’accompagnement, de réactivité, et de transparence.


72 Glossaire | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

Glossaire

Agrégation : Action de calculer les valeurs associées aux positions parentes des dimensions

hiérarchiques. Cette agrégation peut être une somme, une moyenne, ou tout autre processus

plus complexe comme la deuxième plus forte valeur.

Attribut : Un fait décrivant chaque position d'une table.

Axe : Correspond à une dimension

BI : Business Intelligence

Client : demandeur de service

Datamart : L'ensemble des données se rapportant à un des métiers de l'entreprise.

Datamining : L’ensemble des technologies susceptibles d’analyser les informations d’une

base de données pour en tirer les informations utiles

Data Warehouse : Entrepôt de données. Ce terme anglais est utilisé pour désigner l'ensemble

des informations d'une entreprise, enregistrées sous un format informatique.

ETL : Extract Transform Load

Hiérarchie : Les positions d'une dimension organisées selon une série de relations 1- n en

cascade. Cette organisation de données est comparable à un arbre logique, ou chaque membre

n'a pas plus d'un père mais un nombre quelconque d'enfants.

Incident : Arrêt ou dégradation d'un service.

Impayé : Traite ou effet dont le payement n’a pas été effectué à l’échéance.

Multidimensionnel : Structure de données ayant au moins trois dimensions indépendantes.

Niveau hiérarchique : Au sein d'une hiérarchie, les positions sont en général organisées en

niveaux. Les positions d'un même niveau correspondent à une classification précise.

OLAP : On-Line Analytical Processing

Problème : Origine d'un ou de plusieurs incidents récurrents

Processus métier : Succession imposée de tâches à réaliser concernant un métier donné.

SGBD : Système de Gestion de Base de Données

SGBDRO : Système de Gestion de Base de Données Relationnelle et Objet


73 Glossaire | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

SI : Système d’Information

SQL : Structured Query Language

Utilisateur : Personnes utilisant le système décisionnel

Workflow : Flux d'informations au sein d'une organisation. Le terme désigne aussi la

modélisation et la gestion informatique de l'ensemble des tâches à accomplir et des différents

acteurs impliqués dans la réalisation d'un processus métier.


74 Bibliographie | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

Bibliographie

Ouvrages imprimés

iMx Recouvrement et contentieux. - La solution intégrée de gestion événementielle de vos

dossiers.- Paris : CODIX-France.

INMON. - Building the Data Warehouse Second Edition.

Cahier de charges du département des affaires juridiques et du recouvrement.

Circulaire aux banques N°91-24. - Tunisie : 17 Décembre 1991

AXE FINANCE. - Axe credit portal, the next generation solution for credit automation

ISO/IEC Guide 73:2002. - Risk management. - Vocabulary. - Guidelines for use in standards.

Ouvrages électroniques

Jean Marie GOUARNE. - Projet Décisionnel, Enjeux, Modèles, architecture du Data

Warehouse. - Editions Eyrolles, 1997, [référence de mars 2012].

Alain FERNANDEZ. - Le nouveau tableau de bord des managers. - Editions Eyrolles, 2011,

[référence d’Avril 2012].

Alain FERNANDEZ. - L’essentiel des tableaux de bord. - Editions Eyrolles, 2011, [référence de

Mai 2012].

Travaux universitaires

NGUYEN XUEN Dung. - Intégration de bases de données hétérogènes par articulation à

priori d’ontologie : Application aux catalogues de composants industriel. - thèse, Faculté des

sciences fondamentales et appliquées, 22 Décembre 2006.


75 Nétographie | Mise en place d’une solution d’aide à la décision pour le suivi des impayés

Nétographie

[1] http://www.atb.com.tn/ Février 2012

[2] http://www.dictionnaire-juridique.com/ Février 2012

[3] http://www.apce.com/cid51482/l-impaye-n-est-pas-une-fatalite-maitrisez-votre-risque-

client.html?pid=326 Février 2012

[4] http://www.memoireonline.com/09/09/2700/m_La-gestion-du-risque-de-credit-bancaire-

dans-un-contexte-de-crise-economique-Cas-de-la-BNDE-d22.html Février 2012

[5] http://www.sogecor.fr/pages/recouvrement.htm Février 2012 Février 2012

[6] http://www.negociatis.com/electricien/le-recouvrement-de-creances-pourquoi-et-comment

Février 2012

[7] http://www.memoireonline.com/04/07/429/recouvrement-modelisation-informatisation-

du-processus.html Mars 2012

[8] http://www.chefdentreprise.com/Chef-d-entreprise-Magazine/Article/4-bonnes-raisons-d-

externaliser-le-recouvrement-de-ses-creances-20327-1.htm Mars 2012

[9] http://www.memoireonline.com/04/07/429/m_recouvrement-modelisation-

informatisation-du-processus2.html Mars 2012

[10] http://www.sogecor.fr/pages/systeminfo.htm Mars 2012

[11] http://www.dimo-gestion.fr/vdoc/easysite/go/03r-000014-002/solutions/recouvrement

Mars 2012

[12] http://business-intelligence.developpez.com Mars 2012

[13] http://grim.developpez.com/cours/businessintelligence/concepts/conception-

datawarehouse/#LIII-A Mars 2012

[14] http://yves-ducourneau.developpez.com/tutoriels/Business-Intelligence/qlikview-

modelisation-etoile/ Avril 2012

http://www.atb.com.tn/

http://www.dictionnaire-juridique.com/

http://www.apce.com/cid51482/l-impaye-n-est-pas-une-fatalite-maitrisez-votre-risque-client.html?pid=326

http://www.apce.com/cid51482/l-impaye-n-est-pas-une-fatalite-maitrisez-votre-risque-client.html?pid=326

http://www.memoireonline.com/09/09/2700/m_La-gestion-du-risque-de-credit-bancaire-dans-un-contexte-de-crise-economique-Cas-de-la-BNDE-d22.html

http://www.memoireonline.com/09/09/2700/m_La-gestion-du-risque-de-credit-bancaire-dans-un-contexte-de-crise-economique-Cas-de-la-BNDE-d22.html

http://www.sogecor.fr/pages/recouvrement.htm%20Février%202012

http://www.negociatis.com/electricien/le-recouvrement-de-creances-pourquoi-et-comment

http://www.memoireonline.com/04/07/429/recouvrement-modelisation-informatisation-du-processus.html

http://www.memoireonline.com/04/07/429/recouvrement-modelisation-informatisation-du-processus.html

http://www.chefdentreprise.com/Chef-d-entreprise-Magazine/Article/4-bonnes-raisons-d-externaliser-le-recouvrement-de-ses-creances-20327-1.htm

http://www.chefdentreprise.com/Chef-d-entreprise-Magazine/Article/4-bonnes-raisons-d-externaliser-le-recouvrement-de-ses-creances-20327-1.htm

http://www.memoireonline.com/04/07/429/m_recouvrement-modelisation-informatisation-du-processus2.html

http://www.memoireonline.com/04/07/429/m_recouvrement-modelisation-informatisation-du-processus2.html

http://www.sogecor.fr/pages/systeminfo.htm

http://www.dimo-gestion.fr/vdoc/easysite/go/03r-000014-002/solutions/recouvrement

http://business-intelligence.developpez.com/

http://grim.developpez.com/cours/businessintelligence/concepts/conception-datawarehouse/#LIII-A

http://grim.developpez.com/cours/businessintelligence/concepts/conception-datawarehouse/#LIII-A

http://yves-ducourneau.developpez.com/tutoriels/Business-Intelligence/qlikview-modelisation-etoile/

http://yves-ducourneau.developpez.com/tutoriels/Business-Intelligence/qlikview-modelisation-etoile/



[15] http://sia.pagesperso-orange.fr/Net_Methode/4_6_L_informatique_decisionnelle.html

Avril 2012

[16] http://www.guidescomparatifs.com/iso_album/guide_bi_tableaux_de_bord_analyses.pdf

Mai 2012

[17] http://www.easyneo.fr/logiciel-qlikview.php Mai 2012

http://sia.pagesperso-orange.fr/Net_Methode/4_6_L_informatique_decisionnelle.html

http://www.guidescomparatifs.com/iso_album/guide_bi_tableaux_de_bord_analyses.pdf

http://www.easyneo.fr/logiciel-qlikview.php



Annexe A : Dictionnaire complet des données

sources

Table CLIENT

Champ Documentation Type

CODSGE Code siège NOT NULL NUMBER(3)

CPTGNL Compte général NOT NULL NUMBER(4)

CPTPRT Compte particulier NOT NULL NUMBER(6)

NOMCLT Nom NOT NULL VARCHAR2(30)

PRNCLT Prénom VARCHAR2(30)

ADRDOM Adresse domicile NOT NULL VARCHAR2(75)

ACTATB Activité ATB NOT NULL NUMBER(5)

ACTBCT Activité BCT NUMBER(5)

CIN38 Identification NOT NULL NUMBER(7)

CLTTRS Compte cloture NOT NULL NUMBER(1)

VILDOM Ville domicile NUMBER(4)

TYPIDT Type identifiant NOT NULL NUMBER(1)

NUMIDT Numéro identifiant NOT NULL VARCHAR2(15)

NOMABR Nom abrégé VARCHAR2(10)

INDRES Indicateur resident NOT NULL NUMBER(1)

CNATIO Code nationalité NUMBER (3)

FRMJUR Forme juridique NOT NULL NUMBER(2)

NUMTEL Num telephone NUMBER(10)

NUMFAX Num fax NUMBER(10)

ENVCOR Envoi courier NOT NULL NUMBER(1)

VILCOR Ville NUMBER(4)

DATNAI Date naissance NOT NULL DATE

Table CPTCLT : compte client


CODSGE Code siege NOT NULL NUMBER(3)

CPTGNL Compte general NOT NULL NUMBER(4)


TYPIDT Type idt NOT NULL NUMBER(1)

NUMIDT Numéro idt NOT NULL VARCHAR2(15)

CODPRP À ignorer NOT NULL NUMBER(2)

NUMLIS À ignorer NOT NULL NUMBER(4)



INDGRP À ignorer NUMBER(4)

NBRSGN Nbre signataires NOT NULL NUMBER(1)

ADRCOR Adresse courier NOT NULL VARCHAR2(75)

PAYCOR Pays courier NOT NULL NUMBER(3)

VILCOR Ville courier NUMBER(4)

ENVCOR Envoi courier NOT NULL NUMBER(1)

PERECH À ignorer NOT NULL NUMBER(2)

PERREL À ignorer NOT NULL NUMBER(2)

DATREL Date relevé DATE

CODORD À ignorer NUMBER(1)

DATPRE À ignorer DATE

DATECT À ignorer DATE

CLTTRS Compte clôture NOT NULL NUMBER(1)

EDTAVI À ignorer NOT NULL NUMBER(1)

CPTGEL Compte gelé NOT NULL NUMBER(1)

DATGEL Date gel DATE

DATREC Date récupération DATE

DATEOUV Date ouverture NOT NULL DATE

MATEMP Matricule employé NOT NULL NUMBER(4)

DEVCPT Devise compte NUMBER(3)

DATDOP Date dernière opération DATE

CIN38 Identification NUMBER(7)

Table DECGAR : garantie


NUMDEC Numéro de decision NUMBER(9)

CODGAR Code garantie NUMBER(3)

ETAGAR État garantie NUMBER(1)

OBSGAR Observation garantie LONG

MNTEVA Montant évalué NUMBER(13)

DATEVA Date evaluation DATE

NOMEVA Nom évaluateur VARCHAR2(15)

RSVGAR À ignorer VARCHAR2(30)

Table y04pf : impayé financier


Y04BRNM Code agence NOT NULL CHAR(4)

Y04DLP Type de crédit NOT NULL CHAR(3)

Y04DLR Référence credit NOT NULL CHAR(13)

Y04ODLP Code engagement NOT NULL CHAR(3)

Y04DTE Date échéance NOT NULL NUMBER(7)



Y04MVT Type: principal(p) ou intérêt(I) NOT NULL CHAR(1)

Y04MVTS À ignorer NOT NULL CHAR(1)

Y04AMTD Encours impayé NOT NULL NUMBER(15)

Y04AMTP Montant payé NOT NULL NUMBER(15)

Y04OVAM Montant impayé NOT NULL NUMBER(15)

Y04AB Agence NOT NULL CHAR(4)

Y04AN Basic number NOT NULL CHAR(6)

Y04AS Suffix NOT NULL CHAR(3)

Y04EAN Numéro compte NOT NULL CHAR(20)

Table EFFIMPM : impayé commercial

Variable Documentation Type

CODE SGE Code siège NUMBER(3)

CPTGNL Compte general NUMBER(3)

CPTPRT Compte particulier NUMBER(4)

NUMEFF Numéro de l'effet NUMBER(12)

MNTEFF Montant de l'effet NOTE NULL NUMBER(12)

DATECH Date échéance DATE

DATREM Date remboursement DATE

DATREJ Date rejet DATE

CODREJ Code rejet NUMBER(2)

ICODSGE Code siège impayés NUMBER(3)

ICPTGNL Cpte,gén,impayés NOTE NULL NUMBER(4)

ICPTPRT Cpte,part,impayés NONULL NUMBER (6)

CPTTIR Compte tire VARCHAR2(20)

NOMTIR Nom tire VARCHAR2(20)

TYPEFF Type effet VARCHAR2(20)

CODBQE Banque de domiciliation NUMBER(3)

CODVLE Code ville NUMBER(4)

Table Y01PF : encours crédit


Y01BRNM Code agence NOT NULL CHAR (4)

Y01DLP Type credit NOT NULL CHAR (3)

Y01DLR Numéro decision NOT NULL CHAR (13)

Y01CUS Basic number NOT NULL CHAR (6)

Y01DLA2 Montant credit NOT NULL NUMBER (15)

Y01ODLP Code engagement NOT NULL CHAR (3)

Y01DDE Date entrée NOT NULL NUMBER (7)

Y01CTTRD Date decision NOT NULL NUMBER (7)

Y01SDTE À ignorer NOT NULL NUMBER (7)



Y01FDTE Première ech NOT NULL NUMBER (7)

Y01LDTE Dernière ech NOT NULL NUMBER (7)

Y01CCY Devise NOT NULL CHAR (3)

Y01AB Agence NOT NULL CHAR (4)

Y01AN Basic number NOT NULL CHAR (6)

Y01AS Suffix NOT NULL CHAR (3)

Y01EAN Compte oracle NOT NULL CHAR (20)

Y01OVPR Impayé en principal NOT NULL NUMBER (15)

Y01OVIN Impayé en intérêt NOT NULL NUMBER (15)

Y01INT Encous en intérêt NOT NULL NUMBER (15)

Y01PRIN Encours en principal NOT NULL NUMBER (15)

Y01FRQ Remboursement en principal NOT NULL CHAR (3)

Y01IFQ Remboursement en intérêt NOT NULL CHAR (3)

Y01RAT Rate NOT NULL NUMBER (11,7)

Y01MGN Marge NOT NULL NUMBER (11,7)

Y01PAM Mont,init crédit NOT NULL NUMBER (15)

Y01PSDT Date départ agios NOT NULL NUMBER (7)

Table CUMCR : cumul crédit mensuel


CODSGE Code siege NOT NULL NUMBER (3)

CPTGNL Compte general NOT NULL NUMBER (4)

CPTPRT Compte particulier NOT NULL NUMBER (6)

CUM1 Cumul crédit mois1 NUMBER (12)












CUMP1 Cumul crédit mois1 NUMBER (12)














Table RESCOUR cumul crédit quotidien



CPTGNL Compte general NOT NULL NUMBER(4)


MOIS Mois actuel NOT NULL NUMBER(2)

SLDCPT À ignorer

DATDOP À ignorer

MAXSLDC À ignorer

MAXSLDD À ignorer

MINSLDC À ignorer

MINSLDD À ignorer

SLDMOY À ignorer

NBJMVT À ignorer

NBJDB À ignorer

NMDEB À ignorer

NMCRD À ignorer

TMVTDB À ignorer

TMVTCR Total mvt crédit pour le mois NUMBER(9)

ESCFIN À ignorer

ESCCOM À ignorer

IESCFIN À ignorer

IESCCOM À ignorer

DEPOT À ignorer

IMPCHQ À ignorer

VIRCPT À ignorer

DATDJRN À ignorer



Table agiosdébit



CPTGNL Code general NOT NULL NUMBER(4)


AGO1 Agios trim1 NUMBER(6)




AGOP1 Agios trim1 an-préc NUMBER(6)




Table Rfus : fusion échelle d’intérêt


PPLSGE Code siège principal NOT NULL NUMBER (3)

PPLGNL Compte général principal NOT NULL NUMBER (4)

PPLPRT Compte particulier principal NOT NULL NUMBER (6)

ASSSGE Code siège associé NOT NULL NUMBER (3)

ASSGNL Compte général associé NOT NULL NUMBER (4)

ASSPRT Compte particulier associé NOT NULL NUMBER (6)

Table CPTMP_EQ : solde du compte


CODESGE Code siege NOT NULL NUMBER (3)

CPTGNL Compte general NOT NULL NUMBER (4)

CPTPRT Compte particulier NOT NULL NUMBER (6)

SLDFIN Solde su compte NOT NULL NUMBER (15)

SIGNE Signe du solde NOT NULL VARCHAR2 (2)

Table liste chef de zone


CODE Code agence NUMBER(3)

Agence Nom agence VARCHAR2(20)

Guaranties Resp gar VARCHAR2(20)

Contentieux Resp contentieux VARCHAR2(20)

Zone Zone agence VARCHAR2(20)

CHEF DE ZONE Chef zone VARCHAR2(20)



Annexe B : Présentation de Qlikview

La plate-forme QlikView de Business Discovery offre une véritable expérience de BI en libre-

service qui permet aux utilisateurs métiers de prendre des décisions innovantes.

Grâce à QlikView, l’activité est appréhendée de façon différente en :

Consolidant des données pertinentes issues de différentes sources dans une seule et

même application.

Explorant les associations entre les données.

Développant la prise de décisions collaboratives en temps réel et de façon sécurisée.

Visualisant les données à l'aide de graphiques soignés et performants.

Parcourant toutes les données de façon directe et indirecte.

Utilisant des applications, des tableaux de bord et des analyses dynamiques.

Accédant aux données à partir de périphériques mobiles pour les capturer et les

analyser.

Des données aux décisions, un cheminement naturel

Les décisions ne sont pas prises simplement à partir de chiffres mais à partir de différentes

informations provenant de notre environnement, y compris à partir de discussions avec les

personnes qui nous entourent.

Les personnes

Des prises de décisions communes entre collaborateurs grâce à la Business Discovery

collaborative.

Les données

Des analyses basées sur des données d'ERP, de CRM, d'entrepôts de données, de bases de

données SQL, de données Excel, etc.

L'environnement

Des informations en temps réel provenant du terrain grâce à la Business Discovery mobile.

http://www.qlikview.com/fr/explore/products/overview#description_people

http://www.qlikview.com/fr/explore/products/overview#description_data

http://www.qlikview.com/fr/explore/products/overview#description_place

Mise en place d’une solution d’aide à la décision pour PFE/2011_12/Nesrine Dhraief... · Les...

Documents

Transcript of Mise en place d’une solution d’aide à la décision pour PFE/2011_12/Nesrine Dhraief... · Les...