Développement d'une application des taxes rétrocédées à la mairie de Bukavu. Cas de la taxe sur autorisation annuelle de transport urbain.

REPUBLIQUE DEMOCRATIQUE DU CONGO
ENSEIGNEMENT SUPERIEUR, UNIVERSITAIRE ET RECHERCHE
SCIENTIFIQUE
INSTITUT SUPERIEUR DE PASTORALE FAMILIALE

ISPF

USUMA-KIVU

B.P 162 BUKAVU

« Débout face au défis de notre temps »

DEVELOPPEMENT D'UNE APPLICATION DE CONTROLE

ET DE GESTION DES RECETTES RETROCEDEES A LA

MAIRIE DE BUKAVU,

Cas de l a taxe sur Autorisation Annuelle de Transport

Urbain (Taxe voirie)

Présenté par : KASENGE NDUBA junior

Travail de Fin de Cycle présenté en vue de l'obtention du diplôme de graduat en pastorale familiale.

Option : Informatique et Gestion des Ressources Humaines.

Directeur: Ir., Ass. MUGISHO MUSHEGERHA Youen

Année Académique 2015- 2016

Page | II

Préface

« Soit donc que vous mangiez, soit que vous buviez, soit que vous
fassiez quelque autre chose, faites tout pour la gloire de Dieu »

1 corinthiens 1o : 31

Page | III

Dédicace

A ma très chère Mère Christine MU1147A XASOXO'LA ;

A mes deux saurs chéries : MUSEPI NDUBA Margueritte et ASUMINI NDUBA Baby ;

A mon oncle XAIUMBA MUS3CO'LA ECeuthère ;

A tous mes professeurs qui verront dans ce travail Ca fierté d'un savoir bien acquis.

Je dédie ce travail

XASENGE NDUBA Junior

Page | IV

Remerciement

IC serait maChonnête de finir ce travaiC de fin de cycCe sans pour autant remercier Ces personnes qui m'ont soutenu dans toutes Ces circonstances.

Nous tenons à présenter nos sentiments de gratitude premièrement à notre bon Dieu, Jéhovah, de nous avoir donné C'air que nous respirons et de Ca protection qu'iCne cesse de nous manifester.

Nous remercions tous Ces dirigeants de notre chère institution de nous avoir accompagnés scientifiquement durant notre parcours du premier cycCe, Ce graduat.

Nous tenons à présenter nos très sincères sentiments de reconnaissance à notre directeur, C'assistant 3v111GIS3-LO 3v111S3-LEGER3-L.A youen, qui, en dépit de ses études en master à C'EcoCe NationaCe Supérieur de PoCytec hnique (Cameroun), a accepté de mené à bon port ce navire.

Nos remerciements s'adressent aussi à tous Ces membres de ma famiCCe (Papa X.AL113v1B.A 3v1., 3v1aman JuCie B., Ourida X., OrneCCa N., Japhet X., Bénédict B., .Asap h X., yedidia X.) ; à tous Ces membres de Ca famiCCe X.ASENGE en généraC, en particuCier XIT.ANG.A X.ASENGE Etienne pour Ce soutient spiritueC, moraCe, financier, matérieC que vous avez manifesté à mon égard.

.A mes très cher(e)s ami(e)s et coCCègues avec qui nous Cuttons toujours jusqu'au bout, parmi eux nous pouvons cités : Esther Bag., Landry 3v1., Paterne 3-L., Lydia 3v1., Gracia L., Charmant X., Christian 3v1., .Abraham X. Diva X., CCémence 3v1., ,fiston 1Nab., Léandre 3v1., CaCeb S., 3v1eCc hior X., Thérèse O., Xetya X., et surtout à vous dont Ce nom n'est pas cité, nous tenons à vous remercier pour tout.

.A tous ceux-Cà qui nous ont permis de Ces suivre comme Ceurs ombres et qui nous ont toujours donné tant de Ceur temps et confié tant de Ceurs pensées.

X.ASENGE ND11B.A Junior

Page | V

Sigles et Abréviations

AATU : Autorisation Annuelle de Transport Urbain

ADO : Activex Data Object

ATB : Attaché du Bureau

ATLPC : Autorisation Tenant Lieu de Permis de Conduire

CMR : Cellule de Mobilisation des Recettes

COCOMO: Constructive Cost Model

DAO: Data ActiveX Object

DF : Dépendance Fonctionnelle

ETD : Entité Territoriale Décentralisée

GDF : Graphe de Dépendance Fonctionnelle

LCP : Logique de Conception de Programme

MCD : Modèle de Conceptuel des Données

MCF : Modèle Conceptuel de Flux

MCT : Modèle Conceptuel de Traitement

MERISE : Méthode d'Etude et de Réalisation Informatique pour le Système d'Entreprise

MLD : Modèle Logique des Données

MLT : Modèle Logique de Traitement

MOD : Modèle Organisationnel des Données

MOF : Modèle Organisationnel des Flux

MOT : Modèle Organisationnel de Traitement

MPD : Modèle Physique des Données

RDC : République Démocratique du Congo

SGBD : Système de Gestion de Base de Données

SII : Système d'Information Informatisé

SIO : Système d'Information Organisé

SQL : Structured Query Language

TransCom : Transport et voies des communications

UML: Unifield Modeling Language

VBA: Visual Basic for Application

Page | VI

Liste des tableaux

Tableau n° 1 : matrice des flux page 23

Tableau n° 2 : dictionnaire de données brutes .page 25

Tableau n° 3 : dictionnaires des données épurées page 27

Tableau n° 4 : tableau descriptif des objets/entité et leurs propriétés page 34

Tableau n° 5 : tableau descriptif des relations et leurs cardinalités .page 35

Tableau n° 6 : modèle Organisationnel de Traitement .page 39

Page | VII

Liste de figures

Figure n°1 : Modèle Conceptuel de Données page 22

Figure n°2 : Modèle Organisationnel de Flux page 24

Figure n°3 : Graphe de Dépendance Fonctionnelle ..page 30

Figure n°4 : Graphe de Couverture Minimale .page 33

Figure n°5 : Modèle Conceptuel des Données page 36

Figure n°6 : Modèle Conceptuel de Traitement page 37

Figure n°7 : Modèle Organisationnel des Données.... . page 38

Figure n°8 : Modèle Logique des Données page 41

Figure n°9 : Modèle Logique de Traitement page 43

Figure n°10 : Modèle Physique des données page 44

Figure n°11 : page de chargement (loading) .....page 49

Figure n°12 : page d'authentification .page 50

Figure n°13: Menu général encodeur page 50

Figure n°14 : page d'enregistrement de payement .page 51

Figure n°15 : liste des payements enregistrés page 52

Page | VIII

Symboles utilisés

1.

Ecran de l'ordinateur

2. Imprimante

3. Disque Dur

4. Identificateur

5. Documents ou Papiers

6. Unité de traitement

7. Liaison

Page | 1

0. INTRODUCTION GENERALE

C'est devenu une banalité : l'ordinateur s'accapare de nos bureaux, nos écoles, modifie nos modes de travail, envahit nos maisons, s'intègre dans les objets les plus quotidiens et nous propose des loisirs inédits. Il est même à l'origine de nouveaux modes de sociabilité et d'une nouvelle économie.

L'informatique est partout, elle se mêle de toutes les activités humaines et irrigue maintenant la totalité des disciplines scientifiques, modifiant en profondeur leurs pratiques et parfois même leurs natures. À ceux qui affirment que l'informatique n'est pas une science, l'observation du passé récent répond que l'informatique est en réalité une multitude de sciences. Plus encore, la question se pose de savoir si toute la science ne devient pas informatique ! [DEL 2011]

Il est vrai qu'aujourd'hui avec les progrès réalisés dans le domaine des nouvelles technologies de l'information et de communication, la mise en place d'une base de données, permettrait d'atteindre les objectifs assignés.

C'est cette raison qui nous a poussés à circonscrire notre travail à la taxe sur autorisation annuelle des transports urbain (au bureau urbain de transport et voies des communications de Bukavu) en vue d'améliorer efficacement avec efficience les activités que réalise ce bureau.

0.1. Problématique

La problématique est l'approche ou la perspective théorique qu'on décide d'adopter pour traiter le problème posé par la question du départ (qui devient au fil du travail la question centrale de la recherche). Elle est une manière d'interroger les phénomènes étudiés. Construire sa problématique revient à répondre à la question : comment vais-je aborder ce phénomène ? [QUI 2011]

Le système d'information est aujourd'hui un élément central du fonctionnement d'une organisation. Un système d'information peut être défini comme un ensemble de ressources (personnel, logiciels, processus, données, matériels, équipements informatique et de télécommunication, etc. ) permettant la collecte, le stockage, la structuration, la modélisation, la gestion, la manipulation, l'analyse, le transport, l'échange et la diffusion des informations (textes, images, sons, vidéo...) au sein d'une organisation. Parmi les ressources informatiques figurent en particulier les fichiers de données, bases de données et système de gestion de bases de données (S.G.B.D.). [SER 2011]

Eu égard aux problèmes posés ci-dessus et aux questions que nous nous sommes posés ; nous sommes arrivés à émettre les hypothèses qui suivent :

Page | 2

Le fonctionnement optimal des institutions publiques en général et en particulier le bureau urbain des transports et voies des communications est conditionnés par l'utilisation d'un système d'information (logiciels, processus, données, matériels, équipement informatique, etc.) car, la Mairie connait des problèmes liés à l'insuffisance d'un système d'information. Ces problèmes sont entre autres :

+ La canalisation des recettes sur l'autorisation annuelle des transports urbain (Taxe Voirie) ou la traçabilité de ces recettes c'est-à-dire la capacité à suivre depuis la perception de ces taxes jusqu'au dépôt dans la caisse de l'Etat ou chez le comptable de la Mairie (ordonnancement, perception, recouvrement).

+ L'identification de tous les propriétaires des véhicules qui circule dans la ville de Bukavu.

Départ des observations du déroulement des activités et les problèmes constatés au sein de ce bureau, nous nous sommes posés quelques questions :

1. Que peut faire la mairie de Bukavu, à travers les activités du Bureau Urbain des transports et voies de communication, afin d'identifier tous les propriétaires des véhicules qui circulent dans la ville de Bukavu ?

2. Comment faire pour résoudre les problèmes de traçabilité, de flexibilité, de rapidité, de crédibilité et de stockage de données traitées au sein du bureau urbain des TransCom, principalement la taxe sur autorisation annuelle des transports urbain ?

0.2. Hypothèse

Une hypothèse est une proposition qui anticipe une relation entre deux termes qui selon le cas, peuvent être des concepts ou des phénomènes. Elle est donc une proposition provisoire, une présomption, qui demande à être vérifiée. Dès lors, l'hypothèse sera confrontée, dans une étape ultérieure de la recherche, à des données d'observation.

Pour pouvoir faire l'objet de cette vérification empirique, une hypothèse doit être falsifiable. Cela signifie d'abord qu'elle doit pouvoir être testée indéfiniment et donc revêtir un caractère de généralité, et ensuite qu'elle doit accepter des énoncés contraires qui sont théoriquement susceptibles d'être vérifiée. [QUI 2011]

Page | 3

La mise en place d'une base de données intégrée, dynamique et sécurisée devrait permettre à la Mairie de Bukavu de faire l'identification, les recherches et de filtrer les données de tous les propriétaires de véhicules qui circulent dans la ville de Bukavu.

Il serait très judicieux de mettre en place une base des données qui serait rapide, apte, sécurisé et modernisé pour la traçabilité ou la canalisation des recettes que perçoit le bureau urbain de transports et voies des communications. C'est ainsi que la base des données serait une solution aux problèmes que nous avons soulevé durant notre passage dans le bureau urbain de transports et voies des communications.

0.3. Etat de la question

Après avoir fait un tour d'horizon sur des nombreuses études à caractère informatique menées dans le cas des taxes voiries, nous avons remarqué que plusieurs études se sont apaisanties sur l'identification des véhicules, sur la gestion des taxes perçues par la DGDA, sur la gestion des impôts etc. Nous pouvons cités entre autres :

> AIME BABINGWA Georges de l'Institut Supérieur Pédagogique (20112012) : Conception d'une base de données d'identifications des véhicules taxis dans la ville de Bukavu « cas de l'ACCO Bukavu »

> NGOY BIKYEOMBE Vincent de l'Institut Supérieur Pédagogique (20112012) : Gestion automatisée des taxes perçues dans les entités administratives décentralisés « cas du marché de MAKOBOLA dans le secteur de Tanganyika»

> BAKENGANE BAGAYA Steve de l'Université Catholique de Bukavu (20092010) : Gestion Automatisée des taxes prélevées sur les recettes au sein de la Mairie de Bukavu. (Il s'agit d'un mémoire).

Signalons qu'aucune de ces études passées en revue n'ont portées sur l'autorisation annuelle de transport urbain (Taxe voirie). Nos prédécesseurs ont abordés leurs sujets presque similaires au notre, mais dans une optique différente de la nôtre et dans un environnement différent du nôtre.

Notre travail trouve son originalité en ce qui concerne l'identification de tous les propriétaires des véhicules qui roulent dans notre ville, Bukavu et facilitera le contrôle car le logiciel sera capable de fournir ceux qui sont en ordre et ceux qui ne le sont pas ; nous allons améliorer la gestion des droits d'accès à la base des données par rapport aux réalisations de nos prédécesseurs.

Page | 4

0.4. Méthode et techniques utilisées

0.4.1. Méthode

Une méthode c'est la procédure logique d'une science, c'est-à-dire l'ensemble des

pratiques particulières qu'elle met en oeuvre pour que le cheminement de ses démonstrations et des théorisations soit clair évident et irréfutable. [BUG 2015]

La méthode est constituée d'un ensemble des règles qui, dans le cadre d'une science donnée, sont relativement indépendantes des contenus et des faits particuliers étudiés en tant que tels. Elle se traduit, sur le terrain, par des procédures concrètes dans la préparation, l'organisation et la conduite d'une recherche. [BUG 2015]

Dans ce présent travail, nous avons utilisé la méthode MERISE¹ qui est une méthode de conception, de développement et de réalisation de projets informatiques. Le but de cette méthode est d'arriver à concevoir un système d'information. La méthode MERISE est basée sur la séparation des données et des traitements à effectuer en plusieurs modèles conceptuels et physiques. La séparation des données et des traitements assure une longévité au modèle. En effet, l'agencement des données n'a pas à être souvent remanié, tandis que les traitements le sont plus fréquemment. [KAS 2015]

Elle nous a était très bénéfique car elle nous a permis de faire une analyse du système d'information circulant dans le bureau urbain des transports et communications et ensuite développé une application informatique.

0.4.2. Techniques

Une technique c'est un moyen précis pour atteindre un résultat partiel, à un niveau et à

un moment précis de la recherche. Cette atteinte de résultat est directe et relève du concret, du fait observé, de l'étape pratique et limitée. [BUG 2015]

Il existe une multitude des techniques qui peuvent aider un chercheur, mais nous avons pu utiliser seulement ceux qui sont cités ci-dessous :

0.4.2.1. La technique de l'observation

Cette méthode nous a permis de faire une décente sur terrain pour palper du doigt les

faits, comment les activités se déroulent pour une personne ou un véhicule à faire le transport dans la ville. Elle nous a permis aussi d'identifier le flux d'information qui circule entre les différents acteurs qui interviennent dans ce service.

1 Méthode d'Etude et de Réalisation Informatique pour le Système d'Entreprise (et par Sous-Ensembles).

Page | 5

0.4.2.2. La technique de l'interview

L'interview est définie comme étant une technique qui a pour but d'organiser un rapport de communication verbale entre deux personnes, l'enquêteur et l'enquêté, afin de permettre à l'enquêteur de recueillir certaines informations de l'enquête concernant un objet précis. En considérant à la fois la liberté laissée au sujet enquêté et le niveau d'informations recherchées par l'interview. [BRI 1972]

Cette technique nous a été très bénéfique pour couvrir les zones d'ombre que l'observation n'a pas couvert, et ainsi que communiquer avec les fonctionnaires de ce service pour comprendre d'avantage les différents flux d'informations.

0.4.2.3. La technique documentaire

Elle consiste à faire appel aux documents ou des ouvrages dans un domaine précis. Nous avons consulté des archives, des mémoires, des travaux de fin de cycle et des notes de cours, y compris les sites internet.

Elle nous a été fructueuse car elle nous a permis aussi de consulter les différents documents qui circule dans le service et nous permettre d'élaborer les états des sorties qui ressemblent aux documents utilisés dans ce service.

0.5. Choix et intérêt du sujet

Le sujet ne nous est pas choisi, nous l'avons choisi car nous sommes animés par le souci d'améliorer les services qui augmentent le portefeuille de notre chère province, le Sud-Kivu.

L'intérêt scientifique de ce présent travail est de nous permettre d'avoir non seulement le diplôme de premier cycle, de graduat, mais aussi de marier la matière apprise pendant trois ans à une situation concrète, pratique et habituelle.

La Mairie de Bukavu aura un système automatisé, sur base de l'outil informatique capable de gérer de manière automatique et rationnelle les autorisations annuelle de transport urbain et aura un système d'identification des propriétaires des véhicules.

La société aura comme intérêt : les propriétaires des véhicules seront tous connus par la Mairie de Bukavu car ils seront enregistrés dans la base de données et que donc leur identité sera bien gardée ainsi que la marque ou le genre de leurs véhicules.

Page | 6

0.6. Délimitation

Spatialement, nos analyses en vue de développer un système automatisé ont porté essentiellement sur le bureau urbain des transports et voies des communications, se trouvant au sein de la Marie de Bukavu, province du Sud-Kivu, dans la ville de BUKAVU, commune d'Ibanda, sur l'Avenue P. Emery Lumumba, en République Démocratique du Congo.

Chronologiquement, ce présent travail est conçu et réalisé au cours de l'année académique 2015-2016, soit à partir du mois d'Octobre 2015 jusqu'au mois de Juin 2016. Signalons aussi que les recherches ont été effectuées au cours de cette même période.

Analytiquement, nous nous sommes intéressés uniquement aux taxes sur autorisations annuel des transports Urbain (anciennement appelé Taxe Voirie), bien que ce bureau regorge encore d'autres activités qui nécessitent une automatisation.

0.7. Objectifs du travail

L'informatique rend les choses faciles, produit le maximum de résultats avec le minimum d'effort. Pendant que bien des institutions publiques du pays en général et de Bukavu en particulier se facilitent la tâche part l'utilisation des logiciels informatiques pour la gestion de leurs opérations, certaines d'autres ne sont pas toujours au point avec l'évolution de la technologie et continuent à opter pour des solutions manuelles.

L'objectif général que nous nous sommes fixé, n'est pas de changer la manière dont les activités se déroulent pendant la livraison des documents relatifs à la taxe sur l'autorisation annuelle de transport interurbain, mais de les aidés à les effectuer efficacement et avec efficience et essayé de leur rendre la tâche facile pour identifier les propriétaires des véhicules comme ils sont devenus très nombreux dans la ville de Bukavu en mettant à leur disposition un système informatique dynamique et cohérent. Bref, grâce à l'informatique rendre les choses faciles et bannir des solutions manuelles.

Ce travail qui a comme titre « DEVELOPPEMENT D'UNE APPLICATION DE CONTROLE ET DE GESTION DES RECETTES RETROCEDEES A LA MAIRIE DE BUKAVU. CAS DE LA TAXE SUR AUTORISATION ANNUELLE DE TRANSPORT URBAIN (TAXE VOIRIE) », poursuivra spécifiquement les objectifs qui suivent :

V' Comprendre le fonctionnement interne des différents flux d'information lors de la perception de la taxe voirie.

V' Inscrire toute personne qui a un véhicule qui circule dans la ville de Bukavu.

Page | 7

y' Filtrer et limiter les utilisateurs par l'authentification à chaque connexion à la base de données (gestion de droits d'accès).

y' Réserver à l'utilisateur de l'application une interface graphique respectant les normes ergonomiques.

y' Permettre à la mairie de Bukavu de suivre à bon train la traçabilité et la mobilisation de la taxe sur autorisation annuelle de transport urbain qui est l'une des taxes faisant entrer beaucoup de recettes pour la Ville de Bukavu.

0.8. Canevas du travail

Hormis l'introduction et la conclusion de ce travail, il comporte trois chapitres :

Le premier chapitre : « Aperçu sur le bureau urbain des transports et voies de communication » est consacré à la présentation de la maison et nous donnera un aperçu global sur l'autorisation annuelle de transport urbain anciennement appelé Taxe Voirie.

Le second chapitre : « conception du système de gestion de taxe sur AATU », ce chapitre est divisé en deux sections : la première est « conception du système d'information organisé (SIO) », où nous présenterons les différents niveaux conceptuels et différents niveaux d'organisations. Et la seconde : « conception du système d'information informatisé (SII) », nous présenterons ici le niveau logique et ainsi que le niveau physique d'information. Bref, ce chapitre traite sur la modélisation du système que nous étudions.

Le dernier chapitre, « Développement d'une application de contrôle et de gestion des recettes de la taxe sur AATU », le chapitre est focalisé sur la programmation, l'implantation et l'usage ou la description de l'application qui naitra.

0.9. Difficultés rencontrées

Ce travail étant une oeuvre humaine, n'a pas été épargné de quelques difficultés, notamment :

Peu ou presque pas de documentation appropriée dans notre Bibliothèque pouvant servir de modèle pour bien concevoir une base de données.

L'insuffisance des documentations très fournies à notre disposition, aucun ouvrage traitant exactement de taxe voirie.

Page | 8

CHAPITRE I.

APERCU SUR LE BUREAU URBAIN DES TRANSPORTS ET
VOIES DES COMMUNICATIONS

Dans ce chapitre nous donnerons une vue d'ensemble sur la maison ou l'institution qui encadre la taxe sur autorisation annuelle des transports urbain (taxe voirie). Nous commencerons par la Mairie de Bukavu car le bureau urbain des transports et communications est l'un des services technique de la Mairie de Bukavu ; ensuite nous présenterons un survol sur le Bureau urbain des transports et communications qui est un détachement de la division provinciale des transports et voies des communications et enfin nous parlerons de la taxe sur autorisations des transports urbain (Taxe voirie).

1.1. Présentation de la Mairie de Bukavu

La Mairie de Bukavu est la représentation de toutes les communes qui la composent, à savoir : la commune d'Ibanda, la commune de Kadutu et la commune de Bagira.

1.1.1. Historique de la Mairie de Bukavu

C'est en 1901 que des pionniers Belges conduit par le lieutenant OLSEN arrivent dans la presqu'ile de MUHUMBA. Ce poste est laissé sous le commandement d'un chef de poste militaire monsieur CONSTERMANS. Ce poste deviendra plus tard la ville qui porta le nom de CONSTERMANS'VILLE pendant plusieurs années jusqu'en 1952. L'arrêté royal du 30 décembre 1952 nomma la ville Bukavu. Selon la légende locale, les vaches émergeaient les eaux du lac Kivu à la suite d'un rite coutumier animé au son de flute « Karhera ». C'est ainsi que est né le mot « Bukavu » qui est la déformation du mot Shi « Bunkafu ».²

L'acte de création de l'entité ou circonscription territoriale est l'ordonnance loi N° 12/357 du 06 septembre 1958/bulletin administratif de l'année 1958 page 1792, fut l'acte de création de la ville de Bukavu et ses limites administratives seront fixées par l'ordonnance loi N° 21/396 du 29 septembre 1958.

L'urbanisation avait attiré une main d'oeuvre dont regorgeait l'arrière-pays de Bukavu. Elle habitera la proximité de la ville, dont Kadutu appelé Centre extra-coutumier. Au fil des années, il sera surpeuplé, le surplus sera déversé dans un nouveau Centre extra-coutumier de Bagira. Celui-ci était une ancienne concession achetée à l'autorité administrative de l'époque, à Monsieur BORMANS. La pose de la première pierre date de 09 janvier 1954 par le

² Bunkafu : signifiant « attroupement de plusieurs vaches maigres ».

Elle assure l'entretien des places publiques et veille aux respects des règles urbaines et environnementales.

Page | 9

Gouverneur de Province, Monsieur Jean Paul BRASSEU. La ville que contrôle la Mairie de Bukavu compte trois communes dont : Bagira, Ibanda et Kadutu.

1.1.2. Situation géographique de la Mairie

La mairie de Bukavu est située dans l'avenue de la cathédrale N° 035 sur le boulevard P. E Lumumba à quelque mettre de la SONAS succursale de Bukavu, dans le quartier Ndendere (dont le chef est : Médard BALOLAGE MUSHARAMINA), en commune d'Ibanda (bourgmestre : Douglas DUNIA MUKOME), dans la ville de Bukavu.

· Au nord : le lac Kivu et le territoire de Kabare.

· Au sud : le ruisseau Nakakungula dans la vallée de Ruzizi. Elle limite le territoire de Kabare à la ville de Bukavu. A partir de sa source part une ligne conventionnelle qui se dirige à l'Ouest jusqu' à la Rivière Nyamuhinga et sépare les deux entités.

· A l'Est : la Ruzizi charriant les eaux du lac Kivu vers le lac Tanganyika délimite non seulement notre ville à la république Rwandaise, mais aussi celle du Burundi.

· A l'ouest : cette rivière Nyamuhinga descend dans le Nyaciduduma qui se déverse au nord dans le lac Kivu.

1.1.3. Les objectifs de la Mairie de Bukavu

Comme toute institution, la mairie de Bukavu poursuit aussi différents objectifs. Ces sont entre autre de :

y' Assurer l'accomplissement de tache d'intérêt général y' Veiller au maintien de l'ordre public dans la ville y' Lutter contre l'insalubrité et assainir la ville y' Assurer la réhabilitation des voiries urbaines.

La mairie de Bukavu intervient dans l'organisation de certaines activités à caractères social de développement et vient en aide aux personnes victimes des catastrophes naturelles comme : les pluies torrentielles, les érosions ainsi qu'à celles frappées par les accidents et incendies. Elle contribue à l'assurance et à la sécurité des personnes et de leurs biens dans la ville. Elle organise des travaux de réhabilitation des infrastructures de l'Etat.

Page | 10

Pour que la mairie atteigne tous ces objectifs, elle se sert des différents services techniques qui interviennent chacun en ce qui concerne l'exécution de certains travaux au niveau urbain.

1.1.4. Subdivision administrative

La mairie est une entité administrative décentralisée dirigée par le maire et son adjoint. La mairie de Bukavu est subdivisée en trois communes, chacune d'elle est dirigée par un bourgmestre de commune ; celle-ci sont subdivisées en quartier et ceux-ci en commune. La ville compte 3 communes dont celle de Bagira qui compte 3 quartiers, 54 cellules et 149 avenues ; celle d'Ibanda compte également 3 quartiers, 23 cellules et 196 avenues et en fin celle de Kadutu compte 7 quartiers, 19 cellules et 55 avenues.

La mairie de Bukavu est une institution étatique. Elle est reconnue également à travers certaines lois pendant sa création. Comme par exemple : l'ordonnance loi N°21/396 du 29 septembre 1958 qui en a fixé les limites administratives, elle est une entité administrative décentralisée selon la constitution du 16 février 2006 de la RDC.

TABLEAU 1. : Subdivision de commune et quartiers de la ville de Bukavu.

Communes		Quartiers
Ibanda		·	Ndendere
		·	Nyalukemba
		·	Panzi
Bagira		·	Kasha
		·	Nyakavogo
		·	Lumumba
Kadutu		·	Cimpunda
		·	Kajangu
		·	Kasali
		·	Mosala
		·	Nkafu
		·	Nyamugo

Commentaire : ce tableau présente toutes les communes de la ville de Bukavu (à gauche) et leurs quartiers (à droite). Le tableau a été tiré dans les archives de la Mairie de Bukavu.

1.1.5. Organisation structurelle de la Mairie

Partant de celle-ci, il nous revient à démontrer la façon dont les différent bureau et

services sont repartis, les limites de responsabilités de chacun et les relations entre eux. C'est ainsi que nous allons le représenter schématiquement dans l'organigramme et dégager les

missions de services chaque service.

Page 111

ORGANIGRAMME DE LA MAIRIE DE ELTICAVU

LE lLS1RE

LE MIRE ADIOLT DIVISION URBANE

1

FONCTION P. PASSIFS

FONCTION P. ACTIFS

t- NOTARIAT

COI iPTABILTTE URBANE

TRIBUNAL DE P

BUREAU ELDGET

41t-

B.ORDON NCEMENT

AFF_ ECONOMQUES

DISTRICT DE SJ TIE

AFT. SOCIALES

T

DEEP. AGRICULTURE

r^-

BURE: TP_?I

_n~

INSPE CION SOCIALE

AN COMBATIANT

CO_,_...ERC=
EXTEF.IE .7.

BUR URBAIN DE LINDUSTRIE

BUR

TR LNSCD?,ç

BUR 'T BAIN DE SPORTS ET LOISIRS

BUR URBAI DE L'IP A

BUR. vRBAfl DE LA JE;,NFSSE

COMET. DETAT !JRBALti DES EEC=

CO_IL³I.D^.=TAI ;,TiBLJ: DES DEFENSES

CLTLTLTRES ET ARTS

BUREAU.

EN \IRONI.EMENT

DE.. ELOP_ RURAL.

2' BUREAU

SECREIARL&T

COMMUNE DE BAGLRA

? QUARTIERS

I° BUREAU

COMMUNED'IBANDA

3 QUARTERS

SERVICES TECHNIQUES

COMMUNE DE KADTJTU

7 QUARTERS

BUR URBAIN ENERGIE

T B. ;,MAIN DE PLAN

T

B. I;. DE COIkLMUNICATION &EEDIAS

B. URBAIN PRE VOYANCE SOCIALE

B. LREALN DE L^-EPSP

B. URBAN DE B. 'URBAN

LA DGEAD DE LA DGM

B. URBAN DE DROITS MUM ]N

BUR URBAIN DE LA DECENTRiLISA IO'v

B. LRS. DE MINE

r

IME

GENRE ET FAMILLE

t T
BUREAU ITRBAN	BUREAU URBAN DE	PARQUET DE	T PARQUET DE
DE CO MA ANT i LII_AtREVTLLE	COIIIhi,\DEMENT POLICE\TLLE	BUI AV U	GRDE INSTANCE

-4241?.. VILLE

PREV-O}^-,INCE SOCIALE

Page | 12

Source : les archives de la Mairie de Bukavu

1.1.6. Fonctionnement de la Mairie de Bukavu

La mairie de Bukavu fonctionne avec quatre aspects :

> Aspect administratif

> Aspect humain > Aspect financier > Aspect matériel

1.1.6.1. Aspect administratif

Ici, nous voyons directement ce qui est de bureau et services. La mairie travaille avec deux catégories de services :

+ Le service administratif propre de l'institution ou de la mairie.

Ce service émane du ministère de l'intérieur, ce qui fait de la mairie une ETD. Le service administratif de la mairie est subdivisé en 10 services (bureaux), qui sont :

1. Le bureau du maire de la ville ou maire titulaire

2. Le bureau du maire adjoint

3. Le bureau du chef de division urbain

4. Premier bureau

5. Deuxième bureau

6. Secrétariat administratif urbain

7. Comptabilité urbaine

8. Notariat

9. Tribunal de paix anciennement appelé tribunal de ville

10. Trois communes (Ibanda, Kadutu et Bagira). + Les services techniques

Ces services proviennent des différentes divisions provinciales et dépendent de ces divisions, mais pas de la mairie. Ils ont pour rôle de faciliter la mairie à accomplir les tâches lui allouées dans différentes domaines, mais aussi lui permettre l'atteinte de ses objectifs. Ils sont au nombre de 39 dont le Bureau urbain de TransCom qui encadre la taxe sur AATU (Taxe voirie) que nous en parlerons dans les pages qui suivent.

1.1.6.2. Aspect humain ou physique

L'aspect humain marche de pair avec l'aspect administratif c'est-à-dire que la mairie utilise ou fonctionne avec deux catégories des agents.

Page | 13

> Les agents sous statut (matriculés) sont des agents de l'Etat disposant des numéros matricules de la fonction publique et bénéficient d'un salaire mensuel du gouvernement central soumis par le nouveau système de bancarisation. Ils sont au nombre de 41. Pour cette catégorie des agents nous avons :

· Les agents sous statut de services administratifs qui émanent du ministère de l'intérieur.

· Les agents sous statut non mécanisés c'est-à-dire non payé, mais disposant de Numéro Matricule.

· Les agents sous statut de services techniques qui émanent de leurs divisions d'origine ou de leurs ministères de tutelle.

> Les agents sous contrat ou des nouvelles unités sont des agents de l'Etat ne disposant pas encore le NM, mais plutôt de commission d'affectation de la province pour ceux qui sont du ministère de l'intérieur et d'une affectation du ministère de tutelle pour ceux qui sont des services techniques. Les nouvelles unités bénéficient d'une prime locale pour ceux qui sont de l'intérieur et ses collègues de services techniques reçoivent une prime de leurs divisions de provenance sauf pour les services techniques générateurs de recettes qui bénéficient le pourcentage sur les recettes accomplis au compte de la mairie. ils sont aussi au nombre de 15.

1.1.6.3. Aspect financier

Financièrement la mairie fonctionne avec deux volets : + Les recettes locales

La mairie en tant que ETD, dispose de ses taxes locales qui leurs permettent de produire des recettes purement locales. Ces recettes sont gérer par la comptabilité urbaine.

+ La rétrocession

C'est le pourcentage de pourcentages de recettes du trésor public perçues en ville, qui n'appartient pas à cette dernière, mais au gouvernement central. La rétrocession a pour but de faciliter les investissements des ETD et est gérée par la comptabilité chargée de dépenses.

1.1.6.4. Aspect matériel

Pour son bon fonctionnement, la mairie dispose de différents matériels ou outils qui lui facilitent la réalisation de réhabilitation de ses infrastructures à travers son service technique

Page | 14

OVD (Office de Voirie et de Drainage). Elle utilise aussi une main d'oeuvre locale et bien d'autres outils comme les camions, des bêches, tronçonneuses, brouette, etc.

1.2. Présentation du Bureau Urbain des transports et voies des communications

Ce bureau est dirigé par le chef du bureau, du nom d'Adrien NJIRA BAHIZIRE il travaille avec six collaborateurs. Dans le même bureau, nous trouvons un agent de DPMER qui est chargé de l'ordonnancement de notes de perceptions.

1.2.1. Localisation

Le bureau urbain de TransCom se trouve au sein de la Mairie de Bukavu, il est le

premier Bureau Urbain à notre gauche si nous entrons à la Mairie en passant par la voie des véhicules. Le bureau se trouve à l'entrée principale des véhicules dans l'enclos.

1.2.2. Cadre Organique du bureau de TransCom

Ce présent cadre organique est tiré dans le cadre organique de la division provinciale

des transports et voies des communications comme c'est un détachement de la division provinciale. Signalons aussi qu'il est soutenu par L'ARRETE N° CAB.MIN/FP/JMK/PPJ/305/2002 DU 20 DECEMBRE 2002 PORTANT AGREMENT PROVISOIRE DU CADRE ET DES STRUCTURES ORGANIQUES DU SECRETARIAT GENERAL AUX TRANSPORTS ET VOIES DES COMMUNICATIONS.

BUREAU URBAIN DE BUKAVU

1 Chef de Bureau : Anime et supervise les activités du bureau.

1 A.T.B. 1^ere CLASSE : Tenue indicateur, enregistrement du courrier

Entrée/Sortie

1 A.T.B. 1^ere CLASSE : Délivrance des autorisations des transports des

personnes et des biens.

2 A.T.B. 2^ere CLASSE : Tenue d'un fichier des transporteurs urbains et

régionaux, statistiques.

2 A.G.B. 1^ere CLASSE : surveillance de la réglementation, surveillance des

sociétés de transports agréées.

10. G.B. 2^ere CLASSE : contrôleurs routiers.

1.2.3. Principales missions du Bureau

Le bureau urbain des transports et voies des communications a quatre principales missions :

· Réglementation de transport dans la ville de Bukavu

· Perception des droits et taxes de l'entité ville territoire et ceux de la province d'autre part du secteur de transport terrestre.

Nous prenons position pour la deuxième définition car, en RDC, en matière d'impôt ; nous sommes dans le régime déclaratif, cela signifie que c'est le requérant (contribuable) qui se

Page | 15

· La délivrance des documents de bord des véhicules et des motos ainsi que la délivrance des ATLPC.

· Surveillance et le contrôle des agences de transports ainsi que les garages et auto-écoles.

Le bureau urbain de transports et voies des communications encadre deux grandes sortes de recettes (Taxes) :

a) Recettes ou taxes de la Mairie : elles sont régies, par l'arrêté du Maire de la ville :

ARRETE N° 401/BUR/M.BKV/ /2014 PORTANT FIXATION DES TAXES DE
LA MAIRIE DE BUKAVU ADOPTEES PAR LA COMMISION BUDGETAIRE PROVINCIAL DU SUD-KIVU POUR L'EXERCICE 2015.

La taxe sur autorisations annuelle de transport urbain (Taxe voirie), elle se trouve parmi les taxes qu'autorise cet arrêté.

b) Taxe de l'EAD/Province : elles sont régies, par l'arrêté du gouverneur de province : ARREET PROVINCIAL N° 015/003/GP/SK DU 05/01/2015 PORTANT FIXATION DE L'ASSIETTE DES IMPOTS, DROITS, TAXES ET REDEVENCES A PERCEVOIR PAR L'ENTITE PROVINCE DU SUD-KIVU ET LEURS TAUX APPLICABLES AU COURS DE L'EXERCICE BUDGETAIRE 2015.

1.3. Généralités sur les Autorisations Annuelle des Transports Urbain (AATU)

1.3.1. Définitions

1.3.1.1. Taxe

Nous pouvons définir ce terme de plusieurs manières :

Premièrement en Finance (Fiscalité) : c'est un impôt indirect prélevé tout au long du processus de transformation d'un produit ou d'un bien par les entreprises intermédiaire et finalement supporté par le consommateur ; ou un prélèvement fiscal légal direct ou indirect perçu par l'Etat, [ENC 2009]

Deuxièmement : prix acquitté par l'usager d'un service public en contrepartie d'une prestation fournie par celui-ci, [ENC 2009].

Page | 16

présente personnellement au bureau urbain de TransCom muni des documents pour son (ses) véhicule(s) ou moto(s) et déclare ou paye la taxe.

La taxe a comme générateur :

y' Le fait de demander l'autorisation de transport ;

y' Le fait d'exploiter la voirie implique directement le payement d'une contrepartie d'une réparation.

1.3.1.2. Voirie

C'est l'ensemble du réseau des voies de communication appartenant au domaine public (routes, trottoir, etc.)

En administration c'est un secteur de l'administration chargé de l'entretien et de l'aménagement de la voirie (des travaux de la voirie).

1.3.2. Bref historique sur la taxe voirie

La taxe appelée Taxe voirie avait été instituée par la RCD (Rassemblement Congolais pour la Démocratie) ; et après la réunification de la RDC, l'appellation taxe voirie avait été élaguée de la nomenclature. C'est ainsi que par l'ordonnance loi n° 13/001 du 23 février 2013 portant sur fixation de la nomenclature des impôts, des droits, taxes et redevances des provinces et des ETD ainsi leur modalité de répartition, en lieu et place de la taxe voirie, cette ordonnance loi parle désormais « de la taxe sur autorisation annuelle de transport urbain ».

La taxe voirie est aussi née de la décentralisation (qui consiste à opérer le transfert des compétences et des ressources y afférentes du pouvoir central aux autorités/entités locales. Les relations sont alors de tutelle et non de hiérarchie). C'est ainsi que la taxe sur autorisation annuelle de transport urbain se trouve parmi les taxes parafiscales perçues par les provinces et les ETD. Ces taxes sont destinées à être gérées par la direction générale des recettes mais pour le cas de notre province, le Sud-Kivu, ces taxes sont gérées par la DPMER à l'exception de la taxe sur autorisation annuelle de transport qui est gérée par la Mairie de Bukavu.

1.3.3. Importance de la Taxe sur AATU

Comme les véhicules et motos roulent chaque jour et à tout moment dans cette ville, cela a comme conséquence la détérioration de la route, alors comment faire pour prendre soins de cette route ? C'est par la perception de la taxe sur autorisation annuelle de transport urbain. Cette taxe a une seule et unique importance qui est la réparation des routes ou la

Vu la loi organique N° 08/016 du 07 octobre 2008 portant composition, organisation et fonctionnement des ETD et leur rapport avec l'Etat et les provinces

Page | 17

contribution à la réparation des voiries urbaines (tout ce qui concerne les voies de communication urbaines, il peut s'agir des routes, des trottoirs, des rues, des avenues, etc.)

1.3.4. Processus de perception de la taxe

Pour solliciter l'AATU, il faut passer par un processus qui est fixé par la Mairie de Bukavu. On ne peut pas prétendre avoir un véhicule et aller directement à la Mairie sans connaître le processus et aussi sans avoir les documents valables de votre véhicule. C'est ainsi que nous présentons ci-dessous le processus auquel les requérants sont soumis lors de la demande de l'AATU.

1. Etre en possession d'un (des) véhicule(s) ou d'une (des) moto(s) qui roule dans la ville de Bukavu et se présenté au bureau urbain de TransCom (Mairie).

2. Présenté les documents du véhicule ou de la moto à l'agent percepteur

3. Vérification des documents qui lui est présenté, et cela avec comme objectif d'avoir une idée sur la marque de la voiture, son type, son numéro de plaque, son tonnage si c'est un camion, toutes ces informations sont les éléments déterminatif du montant à payer par cas.

4. Communication au requérant le montant à payer

5. Intervient le payement

6. Délivre la quittance ou le document attestant qu'il a payé la taxe.

7. A la fin de chaque journée, le percepteur doit déposer au comptable de la Mairie (comptable urbain) le rapport ou déposer dans le compte de la Mairie.

1.3.5. Nomenclature de la taxe sur AATU

Cette nomenclature est tirée de l'Arrêté du Maire de la ville :

Arrêté N° 401/BUR/M.BKV/2014 portant sur fixation des taxes de la Marie de Bukavu adoptées par la commission Budgétaire Provinciale du Sud-Kivu pour l'exercice 2015.

Vu l'ordonnance loi N° 12/357 du 06 septembre 1985 portant sur la création de la ville de Bukavu ;

Vu l'ordonnance loi N° 81-003 du 17 juillet 1981 portant statut du personnel de carrière des services publics d'Etat.

Vu la loi N° 08/012 du 31 juillet 2008 portant principe fondamentaux relatifs à libre administration des provinces

Page | 18

Vu la loi N° 11/011 du 13 juillet 2011 relative aux finances publique

Vu la loi du 13/001 du 23 février 2013 fixant la nomenclature des impôts, droits, taxes et redevances du pouvoir central, des provinces et des ETD ainsi que les modalités de leur répartition.

Considérant que la Mairie de Bukavu doit réaliser les recettes pour son développement et que pour cette raison elle est indiqué de faire ressortir les taxes prévues dans le présent arrêté ;

Les taxes reprises ci-dessous sont d'offices opérationnels pour le compte de la Mairie de Bukavu.

GENRE ET MARQUE	MONTANT EN DOLLARS	MONTANT EN FRANCS
Jeep et voiture de luxe (puissance fiscale de 8 à 14)	35 $ /an	31 500 FC/an
Voiture ordinaire (puissance fiscale moins de 8)	25 $ /an	22 500 FC/an
Minibus	30 $ /an	27 000 FC/an
Catégorie A (camion de plus de 10 tonnes)	150 $ /an	135 000 FC/an
Catégorie B (camion de moins de 10 tonnes)	85 $/an	76 500 FC/ an
Catégorie C (camionnette de plus de 2 tonnes)	65 $/ an	58 500 FC/ an
Catégorie D (camionnette de moins de 2 tonnes)	40 $ /an	36 000/ an
Catégorie E (bus)	35 $/ an	31 500 FC/ an
Moto	10 $ /an	9 000 FC/ an
Agences BUS	4 $/ Cas	3 600 FC/ Cas
Véhicules immatriculé à l'étranger	50 $ /Bus	45 000 FC/ Bus

En ce qui concerne la validité de la taxe sur autorisation annuelle de transport urbain, elle est annuelle, elle commence du 01 janvier au 31 décembre. Toutefois, après le 31 décembre la Mairie de Bukavu accorde un délai de grâce de 3 mois qui va jusqu'au 31 mars. Dépassé le 31 mars de l'année la taxe est payée avec une pénalité de 50 % pour chaque véhicule.

1.4. Analyse des documents utilisés

Le service qui est chargé de la perception de la taxe sur AATU, utilise des différents documents pour bien s'acquitter de sa mission, parmi ces documents nous pouvons cités entre autres :

1) La fiche de perception : c'est un document que le percepteur rempli une fois avoir reçu les informations concernant le véhicule et le propriétaire. C'est sur ce document où il écrit le nom du propriétaire du véhicule, la marque du véhicule, le genre et le

Page | 19

type du véhicule. Ce document est ensuite donné à l'encodeur pour la saisie ou l'enregistrement dans l'ordinateur. La fiche de perception elle est journalière.

2) Le registre de perception : ce document renferme toutes les informations que contient la fiche de perception à la seule différence que ce document est comme un journal, il est annuel.

3) La quittance : c'est un document qui est imprimé par l'encodeur à donner au requérant comme preuve de paiement ou comme autorisation annuelle de transport.

4) La Nomenclature : c'est extrait de l'arrêté du Maire de la ville où sont clairement définies les catégories des taxes à payer par type et/ou par marque et/ou par genre du véhicule. Ce document sert de de repère pour le percepteur lorsqu'il a en face un requérant pour ne pas lui communiquer un montant qui ne correspond pas à son véhicule.

1.5. Critique de l'existant

La Mairie de Bukavu précisément dans le bureau urbain de TransCom, utilise un tableur Excel pour la sauvegarde des informations concernant les requérants et ainsi que les véhicules et l'impression des quittances. C'est ainsi que nous pouvons dire que la Mairie de Bukavu recours déjà aux solutions automatique et aux solutions manuelles car lors des recherches des informations sont obligés de recourir aux documents manuscrits.

L'utilisation de tableur Excel présente quelques difficultés et parmi eux nous pouvons cités : le volume des données gérées est relativement faibles, la recherche est faible lorsqu'on a beaucoup des données enregistrés sur les différentes listes qui sont indépendantes, et beaucoup tant d'autres difficultés. Nous pouvons donc affirmer qu'Excel n'est pas adapté pour leurs travaux, il peut leur être utile pour les statistiques mais pour les autres tâches, une base des données leurs seraient très utiles.

Page | 20

CHAPITRE II.

CONCEPTION DU SYSTEME DE GESTION DE TAXE SUR

AATU

La Phase de conception nécessite souvent de nombreux choix qui auront parfois des répercutions importantes par la suite. Les théories de l'information ont donc proposés des stratégies ou des méthodes permettant de structurer sa pensée et présenter de manière abstraite le travail que l'on souhaite réaliser. C'est ainsi que tout au long de ce chapitre, qui est divisé en deux sections, la première section : conception du système d'information organisé (SIO) et la seconde section : conception du système d'information Informatisé (SII) nous présentons des différents modèles qui y correspondent et toutes les étapes pour y arriver.

SECTION I: CONCEPTION DU SYSTEME D'INFORMATION
ORGANISE (SIO)

Dans cette partie, nous traiterons des raisonnements que nous avons mis en oeuvre pour l'élaboration des modèles nécessaires à la compréhension et à la conception du système d'information organisationnel (SIO). Nous préciserons ici, comment nous avons élaboré et exprimé les différents modèles de données et traitements de niveau conceptuel et organisationnel qui spécifient ce SIO.

La présentation des différents modèles associées au SIO (MCF, MCD, MCT, MOD, MOT) concerne essentiellement la dimension du cycle d'abstraction (les raisonnements). Cette présentation est faite sans référence aux autres dimensions de la méthode : les cycles de vie et de décision. C'est ainsi que, dans ce chapitre nous arriverons à présenter les différents modèles : MCF, MCD, MCT, MOD, MOT, en commençant par une analyse des flux d'informations ensuite par le recensement des données.

1.1. Définitions de quelques termes clés

1.1.1. Objet (entité) : est un type d'éléments du monde réel défini par : > Une existence propre et utile pour l'organisation étudiée > Les occurrences multiple c'est-à-dire au moins deux > Des propriétés (au moins une) dont un identifiant.

Nous pouvons en distinguer deux sortes : Objet (Entité) régulier(ère) : son existence ne dépend pas de l'existence d'une autre entité ou objet ; Objet (Entité) faible : son existence dépend de l'existence d'une autre entité. [UYE 2015]

> Requérant: est toute personne qui a un ou plusieurs véhicules et/ou une ou plusieurs motos qui demandent ou sollicitent l'AATU.

Page | 21

1.1.2. Relation (Association) : une relation est un lien (une association) qui unit deux entités (objets) ou plusieurs. Contrairement aux entités, les relations n'ont pas d'identifiants et d'existences propres. Les relations sont caractérisées, comme les entités, par un nom et éventuellement des attributs. [KAS 2015]

1.1.3. Propriété (Attribut) : est une information élémentaire (rubrique, donnée) manipulable par le concepteur. Une propriété doit être décrite par un nom de propriété et prendre des valeurs ayant un sens dans le Système d'Informations. Une propriété (attribut) peut être obligatoire ou facultatif et avoir un domaine de valeurs. [KAS 2015]

Une propriété (Attribut) est encore définie comme étant un plus petit élément d'information caractérisant partiellement une entité ou une association. [Bou 2007]

1.1.4. Identifiant : c'est une propriété qui permet de distinguer sans ambiguïté, une occurrence d'une entité de toutes les occurrences. Parmi tous les attributs de l'entité, l'identifiant est un attribut ou un ensemble d'attributs permettant de déterminer une et une seule entité à l'intérieur de l'ensemble.

Nous pouvons en distinguer deux : Identifiant simple : s'il est constitué d'une seule propriété ; Identifiant composé : s'il est constitué de deux propriétés ou plus. [KAS 2015]

1.1.5. Cardinalité : est le nombre de participation d'une entité à une relation. Les cardinalités explicitent les liens qui existent entre entités et associations (relations), c'est-à-dire la participation des associations qui est mesurée au moyen d'un couple des valeurs traduisant le nombre d'occurrences d'entités. [KAS 2015]

1.2. Identifications des acteurs

Un acteur est une personne morale ou physique capable d'émettre ou de recevoir des informations. [CHR 1990].

Un acteur peut être interne ou externe au domaine d'étude. Lors de notre passage à la Mairie (Bureau urbain de TransCom) nous avons pu identifier cinq acteurs dont trois sont des acteurs internes à notre domaine d'étude (les trois premiers) et deux acteurs externes à notre domaine d'étude (les deux derniers). Ces acteurs sont :

Page | 22

> Percepteur: fonctionnaire chargé du recouvrement des impôts ou des taxes. Dans le cadre de notre travail c'est la personne qui perçoit ou la personne au près du quelle qu'on paye l'argent de l'AATU.

> Encodeur : est un Opérateur de Saisi (OPS) qui est chargé d'enregistré tous les requérants dans l'ordinateur qui viennent payer la taxe et imprime une quittance (reçu).

> Comptable urbain : qui est assujetti à rendre des comptes ou la personne qui gère la situation financière de la ville. C'est auprès de cette personne que le percepteur doit donner rapport à la fin de chaque journée.

> CMR (Cellule de Mobilisation des Recettes) : c'est un bureau qui est chargé de mobilisation des recettes de la ville et c'est dans ce bureau que l'Encodeur donne son rapport à la fin de chaque journée.

1.3. Analyse des flux d'informations

Un flux d'information est un mouvement ou un échange des informations qui circulent dans le système (domaine d'étude) ou les informations qu'échangent les différents acteurs.

L'analyse des flux nous permettra d'appréhender simplement le fonctionnement global du système (domaine d'étude), en nous focalisant éventuellement sur un ensemble d'activités concernées par l'étude, sans chercher à identifier l'origine et la stabilité de ce découpage en unités actives, la prise en compte des niveaux d'abstraction (conceptuel, organisationnel, logique, physique) s'effectuera dans les autres modèles.

1.3.1. Modèle Conceptuel des Flux (MCF)

La construction du Modèle Conceptuel de Flux, nous permettra de représenter les flux

échangés entre les domaines d'activité de notre système ou entre les activités de notre domaine d'étude.

C'est l'un des modèle les plus utilisés dans l'analyse des flux d'informations et qui représente les flux échangés entre les acteurs du domaine d'étude et le partenaire extérieur. La procédure

Page | 23

Figure 1 : Modèle Conceptuel des Flux (MCF) LEGENDE

1. Demande d'AATU.

2. Vérification des documents et communication du montant à payer.

3. Le paiement.

4. Enregistrement du requérant sur la fiche de perception et remise de la fiche à l'Encodeur.

5. Encodage des informations reçu, impression et remise de preuves de paiement au requérant.

6. Remise du rapport journalier au comptable.

7. Accusé réception.

8. Remise du rapport journalier au CMR.

1.3.2. Matrice des flux

C'est une représentation matricielle des acteurs et des flux échangés. La matrice des flux est plutôt destinée à l'usage du concepteur pour recenser les flux d'une manière systématique, en s'interrogeant à chaque case. [NAN 2001]

Tableau 1 : Matrice des Flux

Vers De	Requérant		Percepteur	Encodeur		Comptable		CMR		Total Flux
Requérant		-	1 et 3		-		-		-	2
Percepteur	2		-	4		6			-	3
Encodeur	5		-		-		-	8		2
Comptable		-	7		-		-		-	1
CMR		-	-		-		-		-	0
Total Flux		2	3		1		1		1	8

Commentaire :

Les acteurs forment les lignes et colonnes du tableau. Situé en ligne, l'acteur a un rôle d'émetteur de flux ; situé en colonne, il a un rôle de destinataire de flux. Ainsi, en intersection on a le nombre d'occurrences possibles de transaction des flux d'un acteur à l'autre.

1.3.3. Modèle Organisationnel de Flux (MOF)

Le modèle organisationnel de flux est aussi appelé le Diagramme de Flux de

Données (en anglais Data Flow Diagram).

Page | 24

de conception du MOF est : d'abord déterminé le domaine d'étude, c'est-à-dire les domaines d'activité ; ensuite représenter les activités internes sur un domaine ; enfin représenter les flux d'informations échangées entre les activités par des flèches. [KAS 2015].

Figure 2 : modèle organisationnel de flux ou diagramme de flux de données.

LEGENDE

a) Le rectangle avec fond rouge représente le domaine d'étude

b) Les acteurs à l'intérieur du rectangle et en fond jaune représente : sont les acteurs internes au domine d'étude, les autres sont des acteurs externes au domaine d'étude.

c) Les flux 1, 2, 3, 4 et 5 sont des flux internes à notre domaine d'étude ; les flux 6, 7, et 8 sont des flux externes au domaine d'étude.

N.B. : la différence entre MCF et MOF (diagramme de flux des données) se situe au niveau de spécification du domaine d'étude. MCF il ne spécifie pas le domaine d'étude qui est le service d'AATU. Ce domaine d'étude échange des informations avec d'autres services (comptabilité urbain et Cellule de Mobilisation des Recettes).

1.4. Recensement des données

Une base des données ne doit mémoriser que les informations utiles aux traitements réalisés dans l'application concernée. La recherche des données utiles nécessite une enquête (entretien, analyse des documents) d'où il peut résulter des ambigüités qui doivent être élevées. Les informations sélectionnées doivent être éclatées en données élémentaires, de telles façons que ces données ne nécessitent plus la décomposition pour être utiliser. Les données dont les valeurs peuvent être retrouvées par un calcul simple à partir d'autres

Page | 25

données ne sont pas conservées dans la base des données, elles seront plutôt calculées lors du traitement. [UYE 2015]

1.4.1. Dictionnaire des données

1.4.1.1. Définition

Le dictionnaire des données est un document qui permet de recenser, de classer et de

trier toutes les informations (les données) collectées lors des entretiens ou de l'étude des documents. Le dictionnaire peut être plus ou moins élaboré selon le niveau de granularité souhaité. [BAP 2007].

Le dictionnaire des données peut être encore définie comme étant le document dans lequel on récapitule toute les données utiles à une application, or mit les constantes, avec leurs descriptions, leurs natures ainsi que les règles et les contraintes qui s'y rapportent. [UYE 2015].

1.4.1.2. Présentation du dictionnaire de données

Tableau 2 : dictionnaire des données brutes

Nom de la donnée	Code de la donnée	Type de la donnée	Longueur	Nature/Format/obs.	Document
Numéro de la quittance	Num_Quittance	Numéro Auto			Quittance
Propriétaire	Proprietaire	Texte	50
Marque et Type	Marque_Type	Texte	25
Genre	Genre	Texte	25
Plaque du véhicule	Paque_Vehicule	Numérique	6	Xxxx_xx
Puissance Fiscale	Puiss_Fisc	Numérique	5
Montant en chiffre	Montant	Monétaire		Xxxxxxxxxxx_FF
Signature de l'ordonnateur délégué	Signature	Texte
Date de payement	Date_Payem	Date/heure	JJ/MM/AA
Numéro Matricule	Num_Matricule	Numérique			Carte de service percepteur
Nom	Nom	Texte	25
Post Nom	Post_Nom	Texte	25
Prénom	Prenom	Texte	25
Sexe	Sexe	Texte	2
Date de naissance	Date_Naiss	Date/Heure	JJ/MM/AA
Adresse	Adresse	Texte	15

Page | 26

Service	Service	Texte	10
Fonction	Fonction	Texte	10
Numéro de téléphone	Num_phone	Alpha numérique	13	+243 xx xx xx xxx
Adresse mail En	E_mail	texte
Numéro Matricule	Num_Matricule	Numérique			Carte de service encodeur
Nom	Nom	Texte	25
Post Nom	Post_Nom	Texte	25
Prénom	Prenom	Texte	25
Sexe	Sexe	texte	2
Date de naissance	Date_Naiss	Date/Heure	JJ/MM/AA
Adresse	Adresse	Texte	15
Service	Service	Texte	10
Fonction	Fonction	Texte	10
Numéro de téléphone	Num_phone	Alpha numérique	13	+243 xx xx xx xxx
Adresse mail	E_mail	texte
Nom	Nom	Texte	25		Carte rose, Carte d'identité
Post nom	Post_Nom	Texte	25
Prénom	Prenom	Texte	25
Sexe	Sexe	Texte	2
Adresse	Adresse	Texte	15
Date de naissance	Date_Naiss	Date/heure	JJ/MM/AA
Nationalité	Nationalité	Texte	15
Numéro de téléphone	Num_phone	Alpha numérique	13	+243 xx xx xx xxx
Adresse mail	E_mail	Texte
Type véhicule	Type_Vehic	Texte	10
Genre véhicule	Genre_Vehic	Texte	10
Marque véhicule	Marque_Vehic	texte
Puissance Fiscale	Puiss_Fisc	Numérique	5	Xxxxx cv
Numéro plaque véhicule	Plaque_Vehic	Numérique	10	Xx xx -xx

Commentaires :

Dans ce tableau nous avons énuméré les données qui nous serons utiles ou manipulables dans notre base des données. Dans ce tableau, il s'y trouve les redondances (étant la répétition inutile ou non pertinente d'une information), polysémies (deux données portant le même nom ne signifiant pas la même chose ou un mot qui a plusieurs sens ou

Page | 27

équivoque) tous ceux-ci nécessitent une élimination. La donnée Propriétaire c'est une donnée complexe car dans celle-ci nous pouvons y trouver le nom, post nom, prénom etc. alors que dans le dictionnaire de données on ne doit jamais trouver ces genre des données, seulement les données élémentaires (décomposables). Eu égard à cela, nous présenterons maintenant le dictionnaire des données épurées où il y aura absence des redondances, des polysémies et sera constitué uniquement des données élémentaires.

1.4.1.3 Présentation du dictionnaire de épurées

Tableau 3 : dictionnaire des données épurées

N°	Nom de la donnée	Code de la donnée	Type de la donnée	Longueur	Nature/Format/obs.
1	Numéro de la quittance	Num_Quittance	Numéro Auto
2	Montant en chiffre	Montant	Monétaire		Xxxxxxxxxxx_FF
3	Signature de l'ordonnateur délégué	Signature	texte
4	Date de payement	Date_Payem	Date/heure	JJ/MM/AA
5	Numéro Matricule	Num_Matricule_Pr	Numérique
6	Nom	Nom_Pr	Texte	25
7	Post Nom	Post_Nom_Pr	Texte	25
8	Prénom	Prenom_Pr	Texte	25
9	Sexe	Sexe_Pr	texte	2
10	Date de naissance	Date_Naiss_Pr	Date/Heure	JJ/MM/AA
11	Adresse	Adresse_Pr	Texte	15
12	Service	Service _Pr	Texte	10
13	Fonction	Fonction_Pr	Texte	10
14	Numéro de téléphone	Num_phone_Pr	Alpha numérique	13	+243 xx xx xx xxx
15	Adresse mail En	E_mail_Pr	texte
16	Numéro Matricule	Num_Matricule_En	Numérique
17	Nom	Nom_En	Texte	25
18	Post Nom	Post_Nom_En	Texte	25
19	Prénom	Prenom_En	Texte	25
20	Sexe	Sexe_En	texte	2
21	Date de naissance	Date_Naiss_En	Date/Heure	JJ/MM/AA
22	Adresse	Adresse_En	Texte	15
23	Service	Service_En	Texte	10
24	Fonction	Fonction_En	Texte	10

Page | 28

25	Numéro de téléphone	Num_phone_En	Alpha numérique	13	+243 xx xx xx xxx
26	Adresse mail	E_mail_En	texte
27	Numéro de carte	Num_Carte	Alpha numérique	18
28	Nom	Nom	Texte	25
29	Post nom	Post_Nom	Texte	25
30	Prénom	Prenom	Texte	25
31	Sexe	Sexe	Texte	2
32	Adresse	Adresse	Texte	15
33	Date de naissance	Date_Naiss	Date/heure	JJ/MM/AA
34	Nationalité	Nationalité	Texte	15
35	Numéro de téléphone	Num_phone	Alpha numérique	13	+243 xx xx xx xxx
36	Adresse mail	E_mail	Texte
37	Type véhicule	Type_Vehic	Texte	10
38	Genre véhicule	Genre_Vehic	Texte	10
39	Marque véhicule	Marque_Vehic	texte
40	Puissance Fiscale	Puiss_Fisc	Numérique	5	Xxxxx cv
41	Numéro plaque véhicule	Plaque_Vehic	Numérique	10	Xx xx -xx

Commentaires :

La colonne longueur indique la longueur approximative ou exacte de la donnée qui sera entrée par l'utilisateur de la base des données, de même pour le tableau n°2.

Si nous essayons de comparer les deux tableaux (n°2 et n°3), nous remarquons qu'il y a plus des redondances ou des polysémies et dans le deuxième tableau nous avons que des données élémentaires. Comme par exemple, la donnée Propriétaire dans le tableau n°2, a disparue elle n'existe plus dans le tableau n°3 car elle a été décomposée et bien tant d'autres données ont été supprimées car elles dépendaient des autres données.

1.4.2. Représentation de dépendances fonctionnelles des données

La représentation de dépendances fonctionnelles se fait à l'aide des deux outils notamment : la matrice de Dépendance Fonctionnelle et le graphe de DF. Dans ce travail, nous avons jugés bon d'utiliser un seul outil parmi ces deux qui est le Graphe de Dépendance Fonctionnelle car il permet de mieux représenter le lien et surtout les DF à partie gauche composée.

Page | 29

1.4.2.1. Graphe de Dépendances Fonctionnelles (GDF)

Une DF est une interrelation, un lien, une association, une relation entre deux données ou deux groupes de données. On distingue une source et une cible. Retenons que : pour une valeur source, on peut déterminer une et une seule valeur cible. Si, connaissant une valeur d'une donnée A, on peut déterminer une et une seule valeur d'une donnée B, alors on peut dire que B dépend fonctionnellement de A. En d'autres termes, la connaissance de A détermine au plus un seul B, sans avoir besoin de préciser un C.

La construction d'un Graphe des dépendances Fonctionnelles nous permettra plus loin de construire un graphe des couvertures minimales qui nous permettra d'aboutir au MCD

facilement. Une DF A B sera élémentaire si, pour toute partie A incluse dans ou égale à

A, la dépendance A B n'est pas vérifiée. On peut assez facilement en conclure que si A

est réduit à un seul attribut, toute dépendance ayant pour source A sera élémentaire.

Une DF sera direct s'il n'existe pas d'attribut ou d'ensemble d'attributs C tel que

A B C. En d'autres mots A C n'est pas obtenue par transitivité.

Il est possible de visualiser un ensemble de DF élémentaires par un graphe appelé Graphe des dépendances Fonctionnelles (GDF). Celui-ci peut être simple, si les parties gauches des DF sont composées d'un seul attribut. Il peut être complexe si ces parties gauches sont composées

de plusieurs.

Page | 30

Montant

Fonction_Pr Ph

Prenom_Pr

Date_Payem DteP

E_mail_Pr

Signature

Id_Frais

Nom_En

Post_Nom_En

Nom

Prenom_En

Post_Nom

Num_Carte

Sexe_En

Prenom

Sexe

Plaque_Vehic

Adresse

Adresse_En

Date_Naiss

Service_En

Nationalite

Fonction_En

Num_Phone

E_mail

Type_Vehic

Genre_Vehic

uiss_isc_ Puiss_Fisc

E_mail_En

Num_quitta

Nom_Pr Post_Nom_Pr

Marque_Vehic

Sexe_Pr Date_Naiss_Pr

Num_Matricule_Pr

Num_Matricule_En

Adresse_Pr Service_Pr Fonction_Pr

Date_Naiss_En

Num_Phone_En

Figure n° 3 Graphe de dépendance fonctionnelle

Page | 31

Commentaires :

Ce GDF est simple car les sources sont composées par un seul attribut ou donnée. Dans la figure, A est remplacé par la provenance du flèche (source) et B est remplacé par la

destination (cible). Par exemple : Plaque_vehic Num_Carte ; la source c'est
Plaque_vehic et la cible c'est Num_Carte et nous lisons : Plaque_vehic détermine Num_Carte et Num_Carte dépend de Plaque_vehic. Qu'est-ce qu'il faut comprendre par-là ?

Connaissant le numéro de plaque d'un véhicule (Plaque_vehic), nous connaissons le propriétaire du véhicule par le numéro de la carte d'identité ou la carte rose (Num_Carte) car elle est octroyée à une et une seule personne. Mais le contraire est faux, connaissant le numéro de la carte (Num_Carte) on ne saura pas le numéro de la plaque du véhicule (Plaque_vehic) car une personne peut avoir un véhicule ou plusieurs véhicules enregistrés à son nom. C'est de cette manière qu'il faut comprendre les flèches dans la figure.

1.5. Les règles de gestion

Pour une bonne coordination des activités, chaque institution (entreprise, firme, organisation) doit avoir ces propres règles ou règlement d'ordre intérieur. De ce fait, le bureau de TransCom a des règles à suivre pour la gestion de la taxe sur AATU, les voici :

R1 : Un véhicule appartient à une et une seule personne morale ou physique.

R2 : une personne morale ou physique peut avoir un ou plusieurs véhicules.

R3 : le propriétaire du véhicule (Requérant) doit avoir les documents de son véhicule, soit les déclarations douanières ou les documents de l'assurance (si c'est un nouveau véhicule), soit l'ancienne quittance (reçu de l'année passée si c'est un ancien véhicule) et se présenté au bureau de TransCom auprès du percepteur de la taxe.

R4 : le percepteur doit vérifier tous les documents qu'on lui présente et pour tous les requérants.

R5 : le percepteur doit communiquer ou percevoir que le montant qui correspond au type du véhicule et se trouvant sur la nomenclature signé par le Maire de la ville.

R6 : la taxe sur AATU est valide pour une et une seule année civile (du 01 janvier de l'année n au 31 décembre de cette même année n).

R7 : après le 31 mars de l'année n, tous les requérants qui viendront payer la taxe sont soumis aux pénalités de 50 % du montant correspondant au type de leur véhicule.

Page | 32

R8 : l'AATU est valide pour un et un seul véhicule.

R9 : un requérant peut payer pour un ou plusieurs véhicules

R10 : l'encodeur doit imprimer une et une seule quittance pour un requérant.

R11 : le journal de perception doit concorder avec le nombre de véhicule que l'encodeur a enregistré donc le rapport du percepteur doit concorder avec celui de l'encodeur.

R12 : le travail commence à 7h30 et se termine à 15h30 du lundi au vendredi, et de 10h00 à 12h00 le samedi.

1.6. Recensement des objets

1.6.1. Traduction du GDF en schéma entités-relations

La traduction du GDF en schéma Entité- Relations nous permettra de créer les entités, les associations et les cardinalités que nous présenterons dans le MCD plus tard. Pour y arriver, nous passerons par des étapes ci-après :

Etape 1 : Il faut repérer et souligner les identifiants

Etape 2. : Tous les attributs non-identifiants qui dépendent directement d'un identifiant et d'un seul forment une Entité (avec l'identifiant biens sûr).

Etape 3 : les dépendances élémentaires entre les identifiant forment des associations binaires dont les cardinalités maximales sont un (1) au départ de la dépendance fonctionnelle et n (n) l'arrivé.

Etape 4 : sauf si entre deux identifiants se trouve deux dépendances élémentaires réflexive, auquel cas l'association binaire a deux cardinalités maximales valant un.

Etape 5 : Enfin, les attributs non identifiant qui dépendent des plusieurs identifiants sont les attributs d'une association élémentaire dont les cardinalités maximales sont toutes n. [UYE 2015].

Dans la figure ci-dessous, nous avons appliqué que l'étape 1 et 2, les autres seront appliquées

au fur et à mesure que nous évoluons.

Page | 33

Date_Payem

Prenom_Pr

Nom_Pr Post_Nom_Pr

Sexe_Pr Date_Naiss_Pr

Adresse_Pr Service_Pr Fonction_Pr

Num_Phone_Pr

E_mail_Pr

Signature

Nom_En

Num_Matricule Pr

Post_Nom_En

Nom

Num_quittance

Post_Nom

Prenom_En

Prenom

Num_Carte

Sexe_En

Sexe

Plaque_vehic

Num_Matricule_En

Date_Naiss_En

Adresse

Adresse_En

Date_Naiss

IdFrais

Service_En

Nationalite

Montant

Fonction_En

Num_Phone

Num_Phone_En

E_mail

Type_Vehic

Genre_Vehic Marque_Vehic

Puiss_Fisc_Vehic

E_mail_En

Figure n° 4 : graphe de couverture minimale

Page | 34

Commentaires :

En nous inspirant des étapes énoncées ci-dessus, remarquez que les rectangles sont les Entités, et les attributs ou données soulignés sont attributs identifiants des entités et les flèches sont les relations entre les entités. Grâce à ce schéma nous avons clairement repéré les entités, les identifiants et ainsi que les relations entre les entités.

1.6.2. Tableau descriptif des objets ou entités et leurs propriétés Tableau 4 : Tableau descriptif des objets/entités et leurs propriétés

N°	Entité/Object	Codes	Objectifs	Propriété	Nature
1	Requérant	Req	Regroupes toutes les informations concernant le requérant ou le propriétaire du véhicule	Num_Carte Nom Post_Nom Prenom Sexe Adresse Nationalite Num_Phone E_mail	AN AN AN AN A N AN AN AN AN
2	Véhicule	vehic	Regroupe toutes les informations concernant le véhicule	Type_vehic Genre_vehic Marque_vehic Puiss_fisc_vehic Plaque_vehic	AN AN AN N AN
3	Percepteur	Pr	Regroupe toute les informations concernant l'agent percepteur.	Num_Matricule_Pr Nom_Pr Post_Nom_Pr Prenom_Pr Sexe_Pr Adresse_Pr Date_Naiss_Pr Service_Pr Fonction_Pr Num_Phone_Pr E_mail_Pr	N AN AN AN AN AN D AN AN AN AN
4	Encodeur	EN	Regroupe toute les informations concernant l'Agent encodeur.	Num_Matricule_En Nom_ En Post_Nom_ En Prenom_ En Sexe_ En Adresse_ En Date_Naiss_ En Service_ En Fonction_ En Num_Phone_ En E_mail_ En	N AN AN AN AN AN D AN AN AN AN

Page | 35

5	Quittance	Qui	Regroupe les informations relatives au payement	Num_quittance Date_Payem	N D
6	Frais	Frais	Regroupe les informations relatives aux frais que le requérant à payer.	Id_Frais Montant	N M

1.7. Tableau descriptif des relations ou associations

Tableau 5 : tableau descriptif des relations et leurs cardinalités

NO	ENTITES	RELATIONS	CARDINALITES	SIGNIFICATION
1	REQUERANT	APPARTENIR	1, n	Un véhicule peut appartenir à un et un seul requérant, et un requérant peut avoir un ou plusieurs véhicule.
	VEHICULE		1,1
2	ENCODEUR	ENREGISTRER	1, n	Un encodeur peut enregistrer un ou plusieurs véhicules.
	VEHICULE		1, n
3	REQUERANT	RECEVOIR	1, n	Un requérant peut recevoir une ou plusieurs quittances et une quittance est reçue par un et un seul requérant.
	QUITTANCE		1, 1
4	QUITTANCE	CONCERNER	1, 1	Un ou plusieurs frais concerne une et une seule quittance.
	FRAIS		1, n
5	REQUERANT	PAYER	1, n	Un requérant peut payer un ou plus frais et les frais sont payés un et un seul requérant.
	FRAIS		1, 1
6	VEHICULE	CONCERNER	1, n	Un ou plusieurs véhicules peuvent être concerné par un et un seul frais.
	FRAIS		1, 1
7	FRAIS	PERCEVOIR	1, n	Un ou plusieurs frais sont perçus par un ou plusieurs percepteurs. Un percepteur peut percevoir un ou plusieurs frais.
	PERCEPTEUR		1, n
8	QUITTANCE	ETABLIR	1, 1	Une quittance est établie par un ou plusieurs percepteurs et un ou plusieurs percepteurs peuvent établir une et une seule quittance.
	PERCEPTEUR		1, n

1.8. Modélisation des données

1.8.1. Modèle Conceptuel de Données (MCD)

La modélisation c'est une représentation de la réalité ou une image. Le MCD

formalise la signification des informations sur lesquelles repose le système d'information, sans contrainte technique ni économique. [NAN 2001]

Page | 36

Le niveau conceptuel répond à la question quoi ? (le quoi faire, avec quelles données). C'est ainsi que pour le système que nous étudions, le MCD se présente comme suit :

Figure n° 5 : le modèle conceptuel des données (réalisé à partir de JMerise)

1.8.2. Modèle Conceptuel de Traitement (MCT)

Le MCT a pour objectif de représenter formellement les activités exercées par le

domaine d'activités dont la connaissance est la base du système d'information. Elle est tournée vers la prise en compte des échanges du domaine avec son environnement (autres domaines, extérieur de l'entreprise, système de pilotage). C'est avant tout l'identification de ces échanges et des activités induites qui va contraindre et structurer le fonctionnement du domaine. Un MCT exprime ce que fait le domaine, et non par qui, quand, où et comment ces activités sont réalisées. [NAN 2001]

C'est ainsi que l'élaboration du MCT ci-dessous nous permet de préciser les frontières du domaine en décrivant les activités qui lui sont associées et les échanges avec son environnement.

Page | 37

Figure n° 6 : le Modèle Conceptuel de Traitement (MCT)

1.8.3. Modèle Organisationnel des Données (MOD)

Ce modèle est conçu à partir du MCD, la conception du MOD a pour but de quantifier

la Base de Données c'est-à-dire de définir le volume exact de la base des données. Les règles de conception du MOD se résument de la manière suivante :

V' Le MOD se construit à partir du MCD.

V' Si tous les objets (entités) du MCD font l'objet d'automatisation, on dira que le MCD équivaut au MOD. Si non, le MOD est différent du MCD.

V' Si le SI, est du type Client-Serveur, on parle de MOD global pour le serveur correspondant (lorsque la gestion se fait à la Direction Générale), de MOD secondaire pour le client (poste de travail).

V' Le MOD ne comporte que les objets (entités) informatisables. [KAS 2015]

Tableau 6

:

Modèle Organisationnel de Traitement (MOT)

Page | 38

Figure n° 7 : le Modèle Organisation des Données (MOD) 1.8.4. Modèle Organisationnel de Traitement (MOT)

Le MOT s'obtient à partir du MCT en prenant de l'entreprise. Le MCT décrit le « QUOI » du système étudié c'est-à-dire fournit la solution indépendamment de choix de l'organisation. Tandis que le MOT, appelé aussi SOT (Schéma Organisationnel des Traitements) permet de répondre aux questions : qui fait quoi ? ; Où le faire ? ; Quand le faire ? ; Comment le faire ? [KAS 2015]

En d'autres termes la construction du MOT spécifie avec plus de détails le contenu de chaque opération conceptuelle dont l'expression des tâches était jusqu'ici très sommaire et de construire une ou plusieurs solutions d'organisation. A la différence des modèles conceptuels (données ou traitements), l'élaboration d'un organisationnel ne présente pas de difficultés théorique, liée à l'effort d'abstraction. Par contre l'extrême diversité des solutions d'organisation envisageables ou le niveau de détail nécessaire rendent cette phase parfois délicate. [NAN 2001]

Page | 39

DEROULE MENT	ENHAINEMENT			MODE DE FONCTIO NNEMENT	POSTE DU TRAVAIL
QUAND				QUI	OU
De 07h30 à 15h30 De 07h30 à 15h30 De 07h30 à 15h30 De 07h30 à 15h30 De 07h30 à 15h30				TM TM TA TA TA	Perception Perception Encodage Encodage Encodage

Commentaire :

Dans ce tableau, nous avons TM : Tâche Manuelle, TA : Tâche Automatique ; les

opérations s'effectuent de 07h30 à 15h30 car c'est sont les heures de service où sont autorisés ces opérations.

Ici, les règles de transformations pour le passage du MCD au MLD seront en suivant les différents cas qui se posent.

Page | 40

SECTION II: CONCEPTION DU SYSTEME D'INFORMATION
INFORMATISE (SII)

Dans cette partie, qui est consacrée à l'étude du Système d'Information Informatisé (SII), plus précisément à l'articulation des modélisations et formalismes associés. Cette section précisera comment élaborer et exprimer les différents modèles, comment passer d'un niveau d'abstraction au suivant et transformer les différents modèles et enfin, comment aborder toute optimisation.

2.1. Modèle Organisationnel des Données (MLD)

Nous savons qu'une base des données est constituée par un ensemble de tables, dont chacune est composée de champs de données et d'enregistrements. Or, le MCD que nous avons présenté dans le chapitre précédent, ne connaît pas la notion de table, tandis qu'une base des données ne connaît pas le concept des entités reliées entre-elles via des relations portant des cardinalités. Pour cela, il existe un autre modèle, le MLD, qui utilise essentiellement le formalisme des tables logiques. [KAS 2015]

Le MLD fournit une description des données tenant compte des moyens informatiques de mémorisation et de leurs conditions d'utilisation par les traitements. [NAN 2001]

Un MLD, est toujours basé sur le un MCD donné, il contient donc toutes les informations de ce MCD, mais les représente à l'aide d'un formalisme différent qui est très adapté aux structures d'une base des données. Tandis que le MCD représente un système d'information d'une façon générale et indépendante d'un système informatique, le MLD tient compte de la réalisation par le biais d'un SGBD. [KAS 2015]

Bref, le MLD est la suite normale du processus Merise. Son but est de nous rapprocher plus près du modèle physique. Pour cela, nous partons du MCD et nous lui enlevons les relations, mais pas n'importe comment, il faut respecter certaines règles. Voici la procédure :

a) Règles pour les objets du MCD

L'objet se transforme en une table

L'identifiant de l'objet devient la clé primaire de la table

Les propriétés de l'objet deviennent les attributs (champs) de la table ou

relations dans le MCD.

b) Règles pour les relations du MCD

Page | 41

1. Cas de la relation type Père-Fils : il s'agit de transformation des relations binaires du type (x, n)-(x, 1), x pouvant prendre les valeurs 0 ou 1.

2. Cas de Transformation des relations binaires du type (x, n)-(x, n) (x = 0 ou 1) : ici on crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires des deux tables. Lorsque la relation contient elle-même des propriétés, celles-ci deviennent attributs de la table supplémentaire. Une propriété de la relation qui est soulignée devra appartenir à la clé primaire composée de la table supplémentaire.

3. Cas particulier : transformation des relations binaires du type (x, 1)-(x, 1) : nous devons distinguer plusieurs cas. Sachant qu'une relation binaire du type (1,1)-(1,1) ne doit pas exister il nous reste le deux cas suivants : Relation binaire (0, 1)-(1, 1), Relation binaire (0, 1)-(0, 1). [KAS 2015]

Il existe tant d'autres règles pour le passage du MCD au MLD mais ces quelques mentionnés ci-haut nous ont permis d'aboutir à ce formalisme suivant :

Figure n° 8 : Modèle Logique des Données (MLD)

2.2. Modèle Logique des Traitements (MLT)

Le MLT est un ensemble de modèles et de schémas permettant de décrire d'une façon

algorithmique le traitement à réaliser pour chaque opération informatisable d'une application

Page | 42

retenue au niveau du MOT. Il s'obtient donc à partir du MOT, en ajoutant aux traitements organisationnels du MOT, des traitements spécifiques, du mode d'acquisition et d'utilisation des données de l'interface utilisateur.

Dans la pratique, il n'existe pas des règles de passage du MOT au MLT. Ainsi, on recommande une réflexion posée, de la part du concepteur et beaucoup d'intelligence. Cependant, la règle générale dit que pour chaque phase (procédure) informatisable, on doit avoir un début de la procédure et la fin de la procédure. [KAS 2015]

Page | 43

Nomenclature

Percepteur Encodeur

Nomenclature

Requérant

Percepteur

Papiers

Requérant

Papiers

Encodeur

Vérification des documents/payement

-Afficher les marks

- Vérification des données

-Fin de la Vérification et payement

Enregistrement des organes de l'entreprise
-Afficher les marks
-saisir les données
-Fin de la saisie

Début

MAJ
-Afficher les Marks
-MAJ de la liste des requérants
-Fin MAJ

Requérant

Percepteur

Requérant

Encodeur

Visualisation/Edition
-Affichage des données
-Saisie des données
-Fin Edition

Quittance

Fin

Page | 44

Figure n° 9 : Modèle Logique de Traitement (MLT) 2.3. Modèle Physique des Données (MPD)

Le MPD est la traduction du MLD dans une structure de données spécifique au SGBD utilisé. En d'autres termes, c'est la traduction du MLD dans un langage de description des données spécifiques c'est-à-dire mettre le MLD sur un support physique. Le MPD est donc représenté par des tables définies au niveau du SGBD. C'est donc au niveau du MPD que nous quittons la méthode générale de création d'un MCD et de sa transformation en MLD, pour nous tourner vers la manipulation d'un SGBD spécifique. En d'autres termes, c'est la mise en place de ka base de données c'est-à-dire implanter une à une chaque table en créant sa structure puis en la remplissant de données. [KAS 2015]

Le passage du MLD au MPD ne se fait pas au hasard par contre nous devons suivre quelques étapes qui suivantes :

Implémentation physique de chaque table du MLD dans le SGBD utilisé.

Pour chaque table, indiquer au SGBD quel(s) champ(s) constitue(nt) la clé primaire. Pour chaque table, indiquer au SGBD la (les) étrangère(s), de la (les) clé(s) primaire(s) correspondante(s).

Figure n° 10 : Modèle Physique des Données (MPD)

Page | 45

CHAPITRE III.

DEVELOPPEMENT D'UNE APPLICATION DE CONTROLE
ET DE GESTION DES RECETTES DE LA TAXE SUR AATU

Dans ce chapitre, il s'agira en premier lieu de présenter en bref la théorie de base de données dans son intégralité, ses technologies et quelques concepts de base qui sont utilisés dans la base de données. En second lieu, nous présenterons quelques figures ou des illustrations du logiciel ainsi que l'estimation du coût du logiciel.

3.1. Définitions de quelques termes clés

3.1.1. Programmation

La programmation est l'ensemble des activités qui permettent l'écriture des programmes informatiques. C'est une étape importante du développement de logiciels (voire de matériel). Pour écrire un programme, on utilise un langage de programmation. La programmation représente donc ici la rédaction du (ou des) code source d'un logiciel. On utilise plutôt le terme développement pour dénoter l'ensemble des activités liées à la création d'un logiciel et des programmes qui le composent.[WIK 2016]

3.1.2. Conception

La Conception ou le travail de conception consiste à déterminer les solutions techniques qui permettent de satisfaire le cahier des charges et donc répondre aux attentes de l'usager. L'ingénieur se base, sur son expérience, ainsi que sur les patrons de conception, modèles de solutions déjà éprouvés. Il en résulte des diagrammes d'architecture, une description du modèle de données et le diagramme de classes. Les diagrammes utilisent souvent la notation UML. [WIK 2016]

3.1.3. Développement

Le développement c'est réaliser, implanter (installer un logiciel ou un sous-système

donné en réalisant les adaptations nécessaire à leur fonctionnement dans un environnement défini), implémenter (traduire un algorithme dans un langage de programmation) un programme. [ENC 2009]

Page | 46

3.2. Outils de Développement d'une base de données

3.2.1. Implémentation de la Base de données

3.2.1.1. Base de données

Une base de données est un outil permettant de stocker et de retrouver l'intégralité de données brutes ou d'informations en rapport avec un thème ou une activité ; celles-ci peuvent être de natures différentes et plus ou moins reliées entre elles. Dans la très grande majorité des cas, ces informations sont très structurées, et la base est localisée dans un même lieu et sur un même support. Le dispositif comporte un système de gestion de base de données (SGBD) : un logiciel moteur qui manipule la base de données et dirige l'accès à son contenu. De tels dispositifs souvent appelés base de données comportent également des logiciels applicatifs, et un ensemble de règles relatives à l'accès et l'utilisation des informations. [WIT( 2016]

3.2.1.2. Système de gestion de bases de données

Un SGBD (Système de Gestion de Bases de Données) est un logiciel ou ensemble de logiciels destiné à stocker et à partager des informations dans une base de données, en garantissant la qualité, la pérennité et la confidentialité des informations, tout en cachant la complexité des opérations. [LEX 2009]

Pour la conception de notre base de données nous avons fait usage de Microsoft Office Access, dans sa version de 2013 qui est un SGBDR (Système de Gestion de Bases de Données Relationnelles) édités par Microsoft. Nous l'avons préféré car il présente quelques avantages que nous citons dans les lignes suivantes mais aussi parce que ce dernier a fait l'objet principal de la matière vue dans ce premier cycle dans le cadre du cours de LCP I et Access. Microsoft Access (Officiellement Microsoft Office Access) est un SGBD relationnel édité par Microsoft. MS Access est composé de plusieurs programmes : le moteur de base de données Microsoft Jet, un éditeur graphique, une interface de type « Query by Example »3 pour manipuler les bases de données, et le langage de programmation Visual Basic for Applications. Access 2013 intègre de nouvelles fonctionnalités dont de nouveaux thèmes, la modernisation des cinq modèles les plus populaires et l'exportation d'informations de sources de données liées vers Excel. [WIT( 2016]

3 Est un type d'interface utilisateur servant à effectuer des recherches dans des bases de données relationnelles. Le principe d'une interface OBE est que l'utilisateur présente un exemple du résultat de recherche attendu - sous forme d'une matrice, puis le soumet au SGBD

Page | 47

MS Access est un logiciel utilisant l'extension .accdb depuis la version 2007. Il est compatible avec les requêtes SQL et dispose d'une interface graphique pour saisir les requêtes. Il permet aussi de configurer, avec des assistants ou librement, des formulaires et sous-formulaires de saisie, des états imprimables. [WIK 2016]

3.2.1.3. Langage de manipulation de bases de données

ActiveX Data Object ou ADO est une bibliothèque logicielle de Microsoft fournissant une interface d'accès aux données dans l'environnement Windows. Elle permet aux programmes clients d'accéder aux données, et de les manipuler, dans un fichier ou un serveur de base de données. Cette bibliothèque logicielle est une évolution de DAO. Depuis la sortie du Framework .NET, il est utilisé de manière connecté ou déconnecté (dataset). Il est basé sur l'utilisation du format XML, et de l'état des lignes (DatarowState). La version 2 d' ADO.Net, sortie en novembre 2005 avec le Framework 2, apporte des classes indépendantes du moteur d'exécution. [WIK 2016]

ADO ne se limite pas aux bases de données et peut également s'attaquer à d'autres types de fichiers représentant des données structurées (fichier texte ou fichier XML, par exemple). Le grand avantage d'ADO par rapport à DAO (ActiveX Data Objects, Object de données ActiveX) est qu'il permet de se connecter à des bases de données autres que les fichiers de base de données d'Access (.MDB), notamment à des bases SQL Server. Grâce à ADO et aux projets Access (fichiers .ADP), il est ainsi possible de développer une application Access qui serve de frontal à une base de données SQL Server. [DOM 2007]

3.2.2. Environnement de développement

L'environnement dans lequel nous avons développé notre base de données est le Visual Basic for Application (VBA). Pourquoi VBA ? Parce que c'est un langage qui nous permet de gérer un tas de données qui sont sauvegardées dans des tables. Nous l'avons préférée car c'est un langage que nous pouvons affirmer que nous maîtrisons. Dans les paragraphes qui suivent, nous donnons un bref aperçu sur ce langage. La Date de sa première version : 1993, développeur : Microsoft, dernière version stable : 7.1 (office 2013), paradigme : impératif, événementiel, typage : hybride statique/dynamique. VBA est une implémentation de Microsoft Visual Basic qui est intégrée dans toutes les applications de Microsoft Office. Comme son nom l'indique, VBA est très lié à Visual Basic. Il peut cependant être utilisé pour contrôler une application à partir d'une autre. [WIK 2016]

⁴ (Programmation informatique) Pilote, gestionnaire : module, sous-routine gérant une situation particulière comme une exception dans un processus.

Page | 48

VBA est fonctionnellement riche et extrêmement flexible, mais il possède d'importantes limitations, comme son support limité des fonctions de rappel (callbacks), ainsi qu'une gestion des erreurs archaïque, utilisation de Handler⁴ d'erreurs en lieu et place d'un mécanisme d'exceptions. Même si ces limitations rendent ce langage très peu utilisé par les développeurs informaticiens soucieux d'utiliser des outils avant tout performants, sa simplicité et sa facilité d'accès ont séduit certaines professions, notamment dans la finance.

3.2.3. Autres logiciels utilisés

Nous avons fait recours à d'autres logiciels pour la réalisation et la présentation de ce travail, ces logiciels sont entre autres :

> JMERISE, JFLUX, JMCT, JMOT : ces logiciels nous ont été très utiles dans la conception et la présentation des différents modèles de conception dans le chapitre précédent.

> Adobe Photoshop version 4 : pour la création de l'entête de nos formulaires et les états des sorties.

> Ms Word 2013 : pour la saisie de ce travail.

3.3. Description et présentation de l'Application

L'application que nous venons d'implémenter est très simple à utiliser, il ne demande pas trop des connaissances en informatiques pour pouvoir l'utiliser et il faut juste suivre les messages qu'il présente à l'utilisateur. Quelques conditions sont à vérifier au préalable : que la taille du Disque Dur soit supérieur à 500 mégas, processeur de 250 mhz minimum, et qu'on dispose dans l'ordinateur MS office le plus récent (2007, 2010, 2013) mais pas les versions d'avant 2007. Notre application est capable de/d' :

y' Enregistrer le requérant qui viens de payer la taxe sur AATU, le véhicule ainsi que le payement ;

y' Enregistrer les encodeurs et les percepteurs ;

y' Fournir les réponses aux quelques questions comme : qui avait perçu la taxe du véhicule dont la plaque est numéro telle ?, quels sont les payements intervenus

Page | 49

à telle date ?, quelle est la somme totale déjà perçue ?, quelles sont les

véhicules qui ont déjà payé la taxe ?, tel véhicule appartient à qui ?

y' Donner l'accès à chaque utilisateur;

y' Permet de modifier les informations déjà enregistrées ;

y' Imprimer les différents états.

3.3.1. Les menus et interfaces

Au lancement de notre application, nous avons une page de chargement des différents modules (loading) qui nous donne quelques informations sur cette application (le concepteur, le directeur, le titre du projet, etc.)

Figure n° 11 : Page de chargement (loading)

Après cette page d'accueil, l'application vous donne une page d'authentification où l'utilisateur doit choisir sa fonction et taper son mot de passe. Mais attention, lorsque vous essayez à trois reprises un mauvais mot de passe, l'application va vous renvoyez sur page de fermeture qui fermera l'application automatiquement après quelques secondes.

Page | 50

Figure n° 12 : Page d'authentification

Une fois le mot de passe est correct, là l'utilisateur peut accéder aux pages souhaités. Par exemple pour l'encodeur, une fois passer cet étape, par exemple, celle-ci serait vue comme la page d'acceuil :

Figure n° 13 : Menu général encodeur

Signalons aussi que l'encodeur est considéré comme administrateur de la base de données, car lui a accès à toutes les pages et peut ajouter, supprimer et modifier un utilisateur à cette application après avoir reçu l'ordre de son supérieur de le faire. L'encodeur lors de l'enregistrement du payement n'a pas à saisir le montant il apparaitra automatiquement car fonction du genre et marque du véhicule, l'application elle-même effectuera la requête et présentera le montant correspondant au véhicule d'après la nomenclature qu'utilise le bureau de TransCom. Il aura uniquement à choisir le percepteur, le véhicule qui est déjà enregistré et

Page | 51

ensuite cliquer sur « Calculer » et le reste (catégorie, tarif, Pénalité, Total à payer, les informations sur le véhicule et le nom du requérant) s'affichera automatiquement. L'interface pour enregistrer un payement se présente de la matière suivante.

Figure n° 14 : page d'enregistrement du payement

3.3.2. Les états et les requêtes

Nous avons développé plusieurs requêtes ayant une forme similaire. Les états et les

requêtes nous renvoient un résultat et jouent un rôle de recherche dans l'application, ces dernières sont incorporées dans l'application mais ne sont pas visibles, par contre, les résultats des requêtes sont visibles grâces aux états de sorties de l'application. Les états sont imprimables et ressemblent aux documents officiels que le bureau utilise, bref les états sont plus adaptés qu'aux requêtes. Voici l'exemple d'un état de sortie :

Page | 52

Figure n° 15 : liste de payement enregistré

3.4. Coût du logiciel

Pour déterminer le coût du logiciel, il existe beaucoup des méthodes que les concepteurs ou les informaticiens se servent. Nous avons jugés bon d'utiliser la méthode COCOMO (acronyme de l'anglais COnstructive COst MOdel) qui est un modèle permettant de définir une estimation de l'effort à fournir dans un développement logiciel et la durée que ce dernier prendra en fonction des ressources allouées. Le résultat de ce modèle n'est qu'une estimation, il n'est en rien infaillible et parfaitement exact.

Ce modèle, Conçu en 1981 par Barry Boehm, COCOMO est une méthode basée sur les résultats de 63 projets de développements informatiques (allant de 2 000 à 100 000 lignes de code). Elle se base donc sur des statistiques. Aujourd'hui, il existe également le modèle COCOMO II, plus adapté à l'aspect réutilisation des composants. [WIK 2016]

COCOMO est divisé en trois modèles, qui affinent l'estimation en prenant en compte de plus en plus de paramètres :

3.4.1. Principe du modèle

En fonction de la complexité de l'application, on utilisera différents coefficients prenant en compte les différentes complexités et forcément les efforts différents à fournir.

Page | 53

· le modèle de base effectue un simple calcul de l'effort et de la durée en fonction du nombre d'instructions que l'application doit contenir et la complexité de cette dernière. Une ventilation est également possible, permettant de déterminer le temps de développement et l'effort nécessaire pour chaque partie du cycle de développement.

· le modèle intermédiaire reprend l'effort et la durée du modèle de base, en appliquant cette fois-ci des coefficients prenant en compte des facteurs de coût (compétence de l'équipe, complexité de l'environnement technique, etc.).

· le modèle détaillé reprend les données du modèle intermédiaire en affinant notamment les facteurs de coût en fonction de chaque phase du cycle de développement. Ce modèle n'est véritablement nécessaire que pour de très gros projets.

3.4.2. Complexité du modèle

Les complexités des applications à développer peuvent être de trois types :

· S (en anglais organic) : Ce sont des applications simples, n'ayant que peu de cas particuliers et de contraintes. Elles sont parfaitement déterministes.

· P (en anglais semidetached) : Ce sont des applications intermédiaires, plus complexes que les applications de type S, elles restent tout de même déterministes, bien que le nombre de cas particuliers et de tests doivent être plus important que pour les applications de type S

· E (en anglais embedded) : Ce sont des applications très complexes, que ce soit au niveau de leurs contraintes (comme un système temps réel) ou au niveau des données saisies (comme certaines interfaces graphiques où l'on ne peut envisager toutes les possibilités de saisies qu'un utilisateur pourrait effectuer). Elles ne sont pas déterministes.

La catégorisation d'une application dans un type de complexité reste une des choses les plus compliquées à définir dans le modèle de base de COCOMO. En cas de doute et pour ne pas avoir de surprise (comme une sous-estimation de l'effort et donc du temps de développement), il vaut mieux surestimer la complexité d'une application, sans tomber dans l'excès.

Page | 54

Formules

Complexité Effort (en mois homme) Temps de développement (en mois)

S

P

E

KLS (pour Kilo Ligne Source) représente le nombre de milliers d'instructions que contiendra l'application,

Le plus complexe est de déterminer le nombre de KLS. À première vue, on peut se dire que c'est une chose impossible ou avec une très grande marge d'erreur. Cependant, pour être valable le modèle COCOMO ne doit être utilisé que lorsque la phase de conception est déjà bien avancée, de manière à avoir une idée assez précise du travail à réaliser. De plus, l'expérience de la personne utilisant le modèle est déterminante, car il sera ainsi en mesure de s'approcher au plus près du bon nombre de KLS. [WIK 2016]

3.4.3. Application

Vu la théorie qui précède, ce qui nous reste, c'est de mettre en musique les éléments que nous avons pour qu'ainsi estimer le coût de notre application. La formule a utilisée est :

Nos lignes de codes sont environs 600 lignes de codes pour l'ensemble des instructions qui sont dans notre application, c'est ainsi que KLS = 600 (pour Kilo Ligne Source).

Effort = 3 x 600	1.12	= 3	878, 38	3	878
TDev = 2.5 x 3	878	0.35	= 45, 076		45

Coût = Effort + Temps de développement = 3 878 + 45 = 3 923
Le Coût de notre application est estimé à 3 923 $

Page | 55

Conclusion générale

Somme toute, l'idéal au départ de ce travail qui a traité sur la gestion et le contrôle des recettes rétrocédées à la Marie de Bukavu, principalement la taxe sur autorisation annuelle de transport urbain, qui est au terme, était d'apporter notre contribution à la Mairie de Bukavu, précisément le bureau de TransCom en informatisant leur gestion de la taxe sur AATU.

En toute genèse de cette étude, nous avons émis les hypothèses selon lesquelles :

La mise en place d'une base de données intégrée, dynamique et sécurisée devrait permettre à la mairie de Bukavu de faire l'identification, les recherches et de filtrer les données de tous les propriétaires de véhicules qui circulent dans la ville de Bukavu.

La mise en place d'une base de données qui serait apte rapide, sécurisé et modernisé pour la traçabilité ou la canalisation des recettes que perçoit le bureau urbain de TransCom serait très judicieux.

Après le développement et l'implémentation de l'application, nous avons constatés que nos hypothèses ont été confirmées dans le sens où : l'application permet de faire la traçabilité des recettes (qui a payé, auprès de qui il a payé et quel jour il a payé) c'est ainsi que le contrôle est facilité, elle permet d'identifié tous les véhicules qui sont en ordre c'est-à-dire qui ont déjà payé la taxe sur AATU.

Notre application offre aux utilisateurs dédiés une interface graphique respectant les normes ergonomiques, une gestion de droits d'accès, l'utilisateur peut basculer entre les différentes pages qui la constituent. Cet application n'est pas un fruit des tâtonnements mais plutôt celui des recherches approfondies, d'une étude minutieuse et perspicace.

Ce travail est loin d'être meilleur de tous les autres déjà élaborés dans ce domaine, ni même une solution magique avérée, ni même le dernier à être réalisé car nous connaissons actuellement une avancée extraordinaire de l'informatique surtout dans la programmation. Cependant, il constitue une contribution passable pour simplifier les tâches et permet d'atteindre un bon résultat attendu.

Il est vrai que notre application a des limites, des insuffisances, c'est ainsi que nous lançons un appel à d'autres chercheurs, à d'autres programmeurs de pouvoir apporter leur expertise sur cette application. En admettant qu'un travail scientifique n'est jamais parfait, toutes corrections et ajouts à ce dernier sont les bienvenus.

Page | 56

Bibliographie

A) Ouvrages

1. [QUI 2011] : R.QUIVY et L.VAN CAMPENHOUDT, manuel de recherche en sciences sociales, Paris 2011, Dunod, 3^e édition p.101, 139.

2. [BRI 1972] : A. Brino, les méthodes des sciences sociales, Paris, Ed. Montchresnen, 1972, p.207

3. [Bou 2007] : Luc Bouganim, cours de base des données, 2007.

4. [CHR 1990] : Christian Carrez, Des structures aux bases de données, Dunod, Paris, 1990.

5. [NAN 2001] : Nanci D., B. Espinasse avec la collaboration de B. Cohen, J.C. Asselborn et H. Heckenroth (2001), « Ingénierie des systèmes d'information : Merise deuxième génération », Vuibert éditions, Paris. ISBN : 2-7117-8674-9

6. [BAP 2007] : Jean Luc BAPTISTE, MERISE guide pratique : modélisation des données et des traitements langage SQL, édition ENI.

7. [LEX 2009] : Lex de Haan et alli, Beginning Oracle SQL, Apress, 2009, p. 42.

8. [DOM 2007]: Dominique MANIEZ, formation à VBA, Paris, DUNOD 2007, ISBN : 978-2 10-050872-3, p. 257

B) Notes de Cours, TFC et mémoire

9. [BUG 2015] : CT. BUGEME ZIGASHANE Ziga, cours des méthodes de recherche en informatique et gestion des ressources humaines, P.8, ISPF 2014-2015, inédit

10. [KAS 2015] : Prof Nathanaël KASORO MULENDA, support de cours des méthodes d'analyse informatique, UCB 2014-2015, inédit.

11. [UYE 2015] : Notes de cours des Méthodes de recherche Informatique, dispensé par Ass2. Abbé Jean Dominique UYERGIU, ISPF 2014-2015, inédit.

12. Conception d'une base de données d'identification des véhicules taxis dans la ville de Bukavu « cas de L'ACCO Bukavu » AIME BABINGWA Georges ISP 2011-2012

13. Gestion automatisée des taxes perçues dans les entités administratives décentralisés « cas du marché de MAKOBOLA dans le secteur de Tanganyika » NGOY BIKYEOMBE Vincent ISP 2011-2012 TFC

14. BAKENGANE BAGAYA Steve de l'Université Catholique de Bukavu (2009-2010) : Gestion Automatisée des taxes prélevées sur les recettes au sein de la Mairie de Bukavu. (Il s'agit d'une mémoire).

C) Webographie et Encyclopédie

15. [DEL 2011] : DELAHAYE J.-P, encyclopédie universalis, 2011

Page | 57

16. [SER 2011] : S. SERVIGNE, encyclopédie universalis, 2011

17. [ENC 2009] : Microsoft ® Encarta ® 2009.

18. [WIK 2016], https://fr.wikipedia.org/wiki/Programmation_informatique, consulté le 09 mars 2016.

19. [WIK 2016], https://fr.wikipedia.org/wiki/base_des_donnees, consulté le 09 mars 2016.

20. [WIK 2016], https://fr.wikipedia.org/wiki/Microsoft_office_Access, consulté le 10 mars 2016.

21. [WIK 2016], https://fr.wikipedia.org/wiki/visual_Basic_for_Application, consulté le 15 mars 2016.

22. [WIK 2016], https://fr.wikipedia.org/wiki/ActiveX_Data_Objects, consulté le 25 mars 2016.

23. [WIK 2016], https://fr.wikipedia.org/wiki/Constructive_Cost_Model, consulté le 15 Avril 2016.

Page | 58

Table de Matières

Préface II

Dédicace III

Remerciement IV

Sigles et Abréviations V

Liste des tableaux VI

Liste de figures VII

Symboles utilisés VIII

0. INTRODUCTION GENERALE 1

0.1. Problématique 1

0.2. Hypothèse 2

0.3. Etat de la question 3

0.4. Méthode et techniques utilisées 4

0.4.1. Méthode 4

0.4.2. Techniques 4

0.5. Choix et intérêt du sujet 5

0.6. Délimitation 6

0.7. Objectifs du travail 6

0.8. Canevas du travail 7

0.9. Difficultés rencontrées 7

CHAPITRE I. 8

APERCU SUR LE BUREAU URBAIN DES TRANSPORTS ET VOIES DES COMMUNICATIONS 8

1.1. Présentation de la Mairie de Bukavu 8

1.1.1. Historique de la Mairie de Bukavu 8

1.1.2. Situation géographique de la Mairie 9

1.1.3. Les objectifs de la Mairie de Bukavu 9

1.1.4. Subdivision administrative 10

1.1.5. Organisation structurelle de la Mairie 10

1.1.6. Fonctionnement de la Mairie de Bukavu 12

1.2. Présentation du Bureau Urbain des transports et voies des communications 14

1.2.1. Localisation 14

1.2.2. Cadre Organique du bureau de TransCom 14

1.2.3. Principales missions du Bureau 14

1.3. Généralités sur les Autorisations Annuelle des Transports Urbain (AATU) 15

1.3.1. Définitions 15

1.3.2. Bref historique sur la taxe voirie 16

Page | 59

1.3.3. Importance de la Taxe sur AATU 16

1.3.4. Processus de perception de la taxe 17

1.3.5. Nomenclature de la taxe sur AATU 17

Cette nomenclature est tirée de l'Arrêté du Maire de la ville : 17
Arrêté N° 401/BUR/M.BKV/2014 portant sur fixation des taxes de la Marie de Bukavu adoptées

par la commission Budgétaire Provinciale du Sud-Kivu pour l'exercice 2015. 17

1.4. Analyse des documents utilisés 18

1.5. Critique de l'existant 19

CHAPITRE II. 20

CONCEPTION DU SYSTEME DE GESTION DE TAXE SUR AATU 20

SECTION I: CONCEPTION DU SYSTEME D'INFORMATION ORGANISE (SIO) 20

1.1. Définitions de quelques termes clés 20

1.2. Identifications des acteurs 21

1.3. Analyse des flux d'informations 22

1.3.1. Modèle Conceptuel des Flux (MCF) 22

1.3.2. Matrice des flux 23

1.3.3. Modèle Organisationnel de Flux (MOF) 23

1.4. Recensement des données 24

1.4.1. Dictionnaire des données 25

1.4.2. Représentation de dépendances fonctionnelles des données 28

1.5. Les règles de gestion 31

1.6. Recensement des objets 32

1.6.1. Traduction du GDF en schéma entités-relations 32

1.6.2. Tableau descriptif des objets ou entités et leurs propriétés 34

1.7. Tableau descriptif des relations ou associations 35

1.8. Modélisation des données 35

1.8.1. Modèle Conceptuel de Données (MCD) 35

1.8.2. Modèle Conceptuel de Traitement (MCT) 36

1.8.3. Modèle Organisationnel des Données (MOD) 37

1.8.4. Modèle Organisationnel de Traitement (MOT) 38

SECTION II: CONCEPTION DU SYSTEME D'INFORMATION INFORMATISE (SII) 40

2.1. Modèle Organisationnel des Données (MLD) 40

2.2. Modèle Logique des Traitements (MLT) 41

2.3. Modèle Physique des Données (MPD) 44

CHAPITRE III. 45

Page | 60

DEVELOPPEMENT D'UNE APPLICATION DE CONTROLE ET DE GESTION DES RECETTES DE LA TAXE SUR

AATU 45

3.1. Définitions de quelques termes clés 45

3.1.1. Programmation 45

3.1.2. Conception 45

3.1.3. Développement 45

3.2. Outils de Développement d'une base de données 46

3.2.1. Implémentation de la Base de données 46

3.2.2. Environnement de développement 47

3.2.3. Autres logiciels utilisés 48

3.3. Description et présentation de l'Application 48

3.3.1. Les menus et interfaces 49

3.3.2. Les états et les requêtes 51

3.4. Coût du logiciel 52

3.4.1. Principe du modèle 52

3.4.2. Complexité du modèle 53

3.4.3. Application 54

Conclusion générale 55

Bibliographie 56

Table de Matières 58

Annexes 60

Annexes

L'application sur CD