Pour l'ingenieur Cedrick KANDE LWABA.

1. i
ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE
INSTITUT SUPERIEUR PEDAGOGIQUE DE LUBUMBASHI
SECTION D’ETUDES TECHNIQUES
Département d’informatique et scad
Par KANDE LWABA Cedrick
JUILLET 2018
Travail de fin d’étude présenté et défendu en vue de
l’obtention du grade de Licencié en Pédagogie
appliquée
Option : Informatique de gestion
CONCEPTION D’UN SITE WEB POUR LA
REGLEMENTATION DES IMPOTS SUR LE BENEFICE.
« Cas de la Direction générale des impôts/KAPEMBA »

2. ii
ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE
INSTITUT SUPERIEUR PEDAGOGIQUE DE LUBUMBASHI
SECTION D’ETUDES TECHNIQUES
Département d’informatique et scad
Par KANDE LWABA Cedrick
JUILLET 2020
Travail de fin d’étude présenté et défendu en vue de
l’obtention du grade de Licencié en Pédagogie
appliquée
Option : Informatique de gestion
Directeur : PROFESSEUR KASONGO MANDE
CONCEPTION D’UN SITE WEB POUR LA
REGLEMENTATION DES IMPOTS SUR LE BENEFICE.
« Cas de la Direction générale des impôts/KAPEMBA »

3. iii
EPIGRAPHE
Cedrick KANDE LWABA

4. iv
AVANT-PROPOS
Nous voici à la fin de nos études dans le domaine informatique et plus précisément
dans l’informatique de gestion, chaque fin de cycle est sanctionner par une mise en œuvre
d’un travail qui définirait sa fin, cette investigation que nous présentons après cinq années
d’études en informatique de gestion, n’étant pas nous même, nous avons eu des soutiens
venant de plusieurs personnes; voilà pourquoi nous allons remercier nos encadreurs étant
donné qu’ils ont contribué à notre connaissance, nous qui sommes aujourd’hui appelé
informaticien, nos remerciements profonds seraient les plus adressés au professeur Aimé
KASONGO MANDE pour sa disponibilité, ses conseils et assistance nous accordés, à
l’assistant Cedrick DIBWE KITENGE lui qui avait tant des choses à faire mais qui a pu
accepter nous accompagner au cours de la rédaction de ce travail, il serait indigne de terminer
sans exprimer notre reconnaissance au corps Académique de l’Institut Supérieur Pédagogique
de Lubumbashi.
Cedrick KANDE LWABA

5. v
DEDICACE
Se sacrifier pour la vie de ses enfants, ce n’est pas facile pour les parents. Raisons
pour laquelle nous dédions ce travail à vous nos chers Parents LWABA KANDE François et
MUSAU BEYA Katherine vous qui avez fourni des efforts remarquables et vous avez
toujours voulu l’avancement de vos enfants ainsi que vos proches, vous qui ne cessez de nous
conscientiser, notre paresse pour vous c’est une maladie et vous faites en sorte de nous aider
afin d’éliminer la paresse, recevez l’œuvre de vos sueurs.
Cedrick KANDE LWABA

6. vi
REMERCIEMENTS
A vous le grand Dieu d’amour, par sa grâce nous accordé, avons parcouru des
multiples kilomètres pour enfin arriver à cette étape si merveilleuse et nous continuons à
avancer grâce à vous.
A vous très chers frères, sœurs, neveux. Annie LWABA, TSHIDIBI Arlette, Junior
BEYA, Guelord KABAMBA, Betty KANYEBA, Franck LWABA, Dadash LWABA, Jean-
Pierre TSHABA, Vicky TCHEBWE, Simplice NDALA, junior NDJIBU, Fiston TCHEBWE ;
nous vous remercions de nous avoir soutenu(e), nous qui étions de fois incapable d’affronter
seul ce parcours important de notre vie, nous manquons le manifeste à faire pour que vous
remarquiez comment notre cœur est rempli de joie pour vous.
Nous remercions également les familles TCHABA KANDE, KABAMBA
MUBAKOLE, et particulièrement à vous Alain TCHABA, Solange KABAMBA, Packy
TCHABA, Erick KANDE, Mulowayi KABAMBA, Kapy KABAMBA ; nous ne pouvons
passer cette étape sans remercier nos oncles, particulièrement à Tchibwabwa BEYA ainsi que
mes beaux-frères, particulièrement à Prince KANYINDA.
Nos remerciements les plus cordiales sont adressés à nos amis de parcours Francis
KUMOYO, Patient KIKONSHA, Ethienne MBUYI, Emma KAYENDA, Caleb TSHITE,
Kelvin KISULA, Héritier SALUMU, Guelord KISULA.
A tous les amis, en particuliers Derrick MBAZ, Chadrack MANDE, Augustin
MUSHAPATA, Chadrack BUKASA, Christophe NGANDU, Shekinah TSHAKADI et Irène
MBAZ, vous, qui de loin ou de prêt avez contribué tant Spirituellement, Matériellement et
moralement à ce travail; toute notre vie vous sera reconnaissante.
Nous ne pouvons terminer cette étape sans penser à toutes ses personnes qui ont pu
contribuer à ce travail d’une façon ou d’une autre, malgré que vous ne figuré dans notre
mémoire de fin d’étude, ne vous sentez pas éloignées car au fond de nous vous faites partie.

7. 7
LISTE DES FIGURES

8. 8
INTRODUCTION GENERALE
1. PRESENTATION DU SUJET
Depuis notre jeunesse dans le domaine informatique il y a quelques années passées,
ayant une motivation pertinente de trouver un jour une solution dans notre domaine d’étude
pour les entreprises publiques de notre pays et surtout aider notre entourage avec des solutions
authentique, questions de leur permettre à bien gérer leur donnés, se mariant avec les normes
du niveau supérieur, nous recommandent de présenter un travail de fin d’étude, mais cela doit
obligatoirement s’animer grâce à son domaine d’étude, pour qu’en suite nous arrivions à
approuver nos connaissances acquises dans notre parcours de la formation et mettre un
produit d’aide aux entreprises pour leurs gestions.
Actuellement les tendances à l’intérieur des entreprises ont changé de façon à ce que
tous les employés sont des plus en plus régis dans les différents domaines liés à la gestion et
exploitation de données de cette manière, et du coté des clients, l’influence devient de plus en
plus interresser par le E-commerce, autre niveau de connaissance de principes et des outils
standard de l’informatique , Est actuellement pour la plus part des postes disponibles dans les
entreprises.
L’informatique en tant que science du traitement automatique de l’information
d’une manière rationnelle par l’Ordinateur gagnera cette partie. Un ordinateur pur invention
humaine est une machine capable de recevoir les données, de les traiter de façon logique et de
produire les résultats. (1)
Pour la commune KAPEMBA, l’informatique vas nous présenter plusieurs avantages
de cette technologie en rapportant des méthodes techniques notamment une gestion
informatisée efficace et appropriée pour gérer les contribuables de manière efficace de l’impôt
sur le bénéfice ainsi sécuriser ces données.
C’est pourquoi nous allons orienter cet outil informatique pour faciliter la gestion de
contribuable. Le travail que nous allons traiter est intitulé « Conception d’un site web pour
la règlementation des impôts sur le bénéfice». (Cas de la Direction générale des
impôts/KAPEMBA)
2. ETAT DE LA QUESTION
1 FARR, J., généraux informatiques, Paris 2006,citépar MPALA-MBABULA, L., Pour vous chercheurs,directive
pour rédiger un travail scientifique

9. 9
Dans la réalisation d’un projet les chercheurs ont tendance à recourir à une documentation
qui va leur permettre de biens réaliser leurs projets. Ce qui fait dire à Reginald RECLIFFE
BROWN que « chaque chercheur prend comme point de départ les travaux de ses
prédécesseurs, découvre les problèmes qu’ils croient significatifs ».2
C’est pourquoi nous avons jeté un coup d’œil dans les travaux scientifiques de nos
prédécesseurs, nous avons lu comme travail :
1. KIBUTA KASEBULA C. Dans son travail intitulé : « Conception d’une
application web de suivi des déclarations des contribuables dans un centre
d’impôt». (Cas de la DGI/KATANGA) 3 : Dans son travail elle constate que, la
direction des recettes du haut Katanga manque une base de données qui est
efficace et solide pour traite les données et les informations sur le contribuable de
l’impôt foncier ;
 Sur la perte des informations.
 Sur le non confidentialité des données.
Comme solution ; Elle propose à mettre en place une base de donnée pour une gestion
efficace des déclarations de l’impôt foncier. Cette technologie à faciliter toutes les taches.
2. ELKEYA KITEDWE BEATRICE « Mise En Place d’une Base De Données
Partagées De Gestion Des Recette De l’impôt Foncier A La Direction De Recettes
Du Haut Katanga»4 dans son travail elle dit que lors de sa descente sur terrain, elle
a remarqué que, il y avait les problèmes suivants :
 La fraude et les détournements de fonds ;
 La perte de certaines pièces justificatives de contribuable (copies) liées
à l’impôt.
Comme solution ; elle a mis en place une base de données qui partages la gestion des
recettes liées à l’impôt foncier.
Voici les grands points sur lesquels nous nous sommes basés et qui marque une ligne
de conduite entre nos prédécesseurs et nous, dans notre projet de recherche, nous allons
mettre une solution au sein de la Direction générale des impôts kapemba et dans notre cas il
2 RECLIFFE, B., R., structure et fonction dans les sociétés primitives, éd. De Minuit, Paris, 1976,P.126.
3 KIBUTA KASEBULA C. «Miseen placed’une basede données partagées de gestion des recettes de l’impôt
foncier a la direction derecettes du haut haut-Katanga»,Isp,2018
4 ELKEYA KITEDWE BEATRICE « MiseEn PlaceD’une BaseDe Données Partagées De Gestion Des Recette De
L’impôt Foncier A La Direction De Recettes Du Haut Katanga », Isp,2018

10. 10
ne serait pas question de mettre une application web mais un site web qui vas permettre à leur
bureaux de communiquer facilement rapidement et surtout la circulation rapide des
informations.
3. CHOIX ET INTERET DU SUJET
3.1. Choix du sujet
Toute décision est un drame qui consiste dans le sacrifice d’un désir sur l’autel d’un
autre désir.5 Ce sujet n’est pas un hasard mais se dans le souci d’informatisé le contribuable
des impôts sur le bénéfice dans l’entité de la Commune Kapemba.
3.2. Intérêt du sujet
a. Intérêt personnel
Tout est définie dans notre présentation du travail ou nous présentons le topique
de notre parcours en informatiques, raison pour laquelle le présent travail s’avère
indispensable tel d’un produit scientifique original consacrant non seulement notre travail de
fin d’études pour l’obtention du titre de licencié mais aussi un outil fourni au monde des
chercheurs dans le domaine informatique d’une part et d’autre part, ce travail nous permettra
d’approfondir notre connaissances sur toutes les entreprises payant l’impôt sur les bénéfices.
b. Intérêt social
Cet outil ne sera pas bénéfique qu’a nous chercheur, comme je l’ai dit dans ma
présentation, mais le but est d’arrivée à trouver des solutions pour l’état congolais et surtout
notre entourage, raison pour laquelle le centre des impôts synthétiques qui va bénéficier de
notre site web dans son entité, ce qui va le permettre de bien travailler.
c. Intérêt scientifique
L’intérêt scientifique peut s’étendre comme l’apport que l’étude d’un fait social donné
ajouté à la science.6 Le meilleur moyen de prédire l’avenir c’est de l’inventer dit RELAY,
ainsi par ce travail nous avons mis une amélioration dans le domaine informatique plus
précisément en informatique, pour une génération future de faire référence à une analyse et à
5 Citation,choix,DictionnaireLarousse.
6 Massaer DIALLO, Politologue,« Défis sécuritaires ethybridations des menaces dans la zone sahélo
saharienne»,séminairesur la sécuritéau sahel,Bruxelles,p,3, 2010.

11. 11
une conception d’une solution informatique plus concret et réaliste et surtout plus adapter aux
réalités actuelles qui vivent l’évolution technologique.
4. PROBLEMATIQUE ET HYPOTHES
5.1. PROBLEMATIQUE
A ce propos, VIGNOLES P. Souligne que la problématique est le jeu des questions
liées entre elles et tirées du sujet lui-même auxquelles le développement va progressivement
répondre.7
Pour Louis MPALA BAMBULA « La problématique représente le but vers lequel
tend l’introduction. Elle est l’angle sur lequel va s’étendre un travail. La problématique elle
seule poursuit-il, justifie le choix du plan qui, n’est qu’une réponse à l’interrogation qu’elle
sous-entend »8
Pour le professeur VICTOR KALUNGA pour sa part pense que la problématique
est la question principale que l’auteur se pose à l’esprit et à laquelle il attend répondre au bout
de ses recherches. Elle doit, selon lui être formulée de sorte qu’elle puisse s’allier directement
au thème contenu dans le sujet. Une seule question, poursuit-il ?, suffit à titre de
problématique, à la rigueur l’on peut admettre deux questions qui seraient complémentaires.9
Selon le dictionnaire Larousse, la problématique est l’ensemble des problèmes qui se posent
sur un sujet.
De ce fait, nous pouvons définir La problématique comme étant l’ensemble des questions
qu’un chercheur se pose, pour résoudre un problème donné. Voici quelques problèmes relevé
au sein de cette entité :
 Irrégularité dans les recensements du nouveau contribuable.
 Nombre important des archives qui engendre une difficulté de stockage et aussi
une détérioration des archives à force de leur utilisation trop fréquente dans
l’entreprise.
7 VIGNOLES, P., La dissertation philosophique au bac, hâtier, paris, 1985, P .68.
8 MPALA BAMBULA L. Pour vous chercheur, L’shi, ed mpala, 2011,P.87
9 Cfr. VICTOR, KALUNGA, la rédaction des mémoires en droit guide pratique,P.13-14.

12. 12
 Le traitement de données est manuel ce qui cause une lourdeur des opérations sur
différents postes de l’entreprise.
 Retard dans la transmission de rapport dans les autres bureaux du centre, ce qui
crée des incompréhensions dans l’élaboration des rapports hebdomadaires et
surtout mensuel.
 Lenteur dans la recherche des informations ce qui crée un long file d’attente dans
les salles de travail.
Pour n’est pas échapper à l’idée claire de la question de recherche, nous nous somme
posé la question que voici : comment nous pouvons sortir la direction générale des impôts
kampeba dans cette situation anormale ou il y a différents problèmes relever ci-haut?
5.2. HYPOTHESE
RONGERE dit d’elle « une proposition particulière de réponse à la question que
l’on se pose à propos de l’objectif de la recherche formulé en des termes tels que
l’observation et l’analyse puissent en fournir une réponse ».10
L’hypothèse est définie par GORDON MACE « comme une réponse anticipée
que le chercheur formule à sa question spécifique de recherche ».11
Selon le dictionnaire encyclopédique l’hypothèse se définit comme une interprétation
anticipée et rationnelle des phénomènes de la nature.12 Nous pouvons aussi définir
l’hypothèse comme étant un mode de raisonnement qui sert d’apriori d’une affirmation ou
d’une proposition, il s’agira par la suite de confirmer par le résultat de la recherche.
Comme projet ou hypothèse, nous suggérons de créer un site web pour la gestion du
contribuable liée à l’impôt sur le bénéfice, qui pourra résoudre les problèmes soulevés dans
notre problématique.
5. METHODE ET TECHNIQUE
6.1 Méthode
10 ONGERE, P., cité par MULUMBATI, Nb., le manuelde sociologie générale,africa, Lubumbashi,1987,P.17.
11 MACE, G., guide d’élaboration d’un projet de recherche, les presses de L’université de Laval, Québec,1988,P.35.
12 DictionnaireEncyclopédique

13. 13
PINTO et GRAWITZ définissent la méthode comme étant un ensemble des opérations
intellectuelles par lesquelles une discipline cherche à atteindre les vérités qu’elle poursuit, les
démontrent et les vérifient. 13
FREYSSINET dit d’elle « une procédure logique et désintéressée, comme à toute
démarche scientifique et articulée en un ensemble de règles d’application générale».14
Ainsi, dans notre travail nous allons utiliser la méthode agile UP (Unified
Process) qui est un processus unifié ; qui cadre avec l’analyse et la conception orientées objet.
Le processus unifié UP est un processus de développement logiciel de qualité, « centré sur
l’architecture, piloté par des cas d’utilisation et orienté vers la dimension des risques ».15
Cette méthode est le talent de rendre réalisable le maniement d’une base de données et elle
permet aussi de créer une représentation potentielle d’une réalité; de telle sorte à faire ressortir
les points auxquels on se consacre.
6.2 TECHNIQUE
La technique est un ensemble de procédure ou des méthodes mené par un chercheur
scientifique, pour donner un résultat bien déterminé. Et pour la collecte des informations
nécessaires à la réalisation de ce travail, nous avons recouru aux techniques ci-après :
 La technique documentaire: s’appuyant sur la consultation des documents,
cette technique nous a permis de recueillir les informations nécessaires
relatives à notre travail par la consultation d’ouvrages, des notes de cours, des
sites et articles et des différents travaux réalisés ici et ailleurs ayant un
quelconque rapport avec notre travail.
 La technique d’interview: cette technique nous a permis au Travers des
différents échanges que nous avons eu avec les responsables des services de
réservation des différentes compagnies d’aviations, d’avoir les informations
relatives’ à la réalisation de notre solution informatique.
13 PINTO ET GRAWITZ CITE PAR MULOWAYI, coursd’initiation à la recherche scientifique, G2 IG,
2017-2018,page 31
14 John MULOWAYI & Michel ZONGWE, initiation à la recherche scientifique, s.l, ISP, 2016,P.49.
15 Pascal ROQUES, UML2 Modéliser une application web,4ème Edition, Eyrolles, Paris, 2008

14. 14
 La technique d’observation directe : c’est par cette technique nous avons pu
observer, dévisager, fixer tous ce qui se passe dans l’entreprise, pour enfin
produire une analyse complète du système.
6. DELIMITATION DU TRAVAIL
Tout travail scientifique pour être bien compris et bien abordé mérite d’être délimité
dans le temps et dans l’espace. Ainsi, nous avons subdivisé notre travail de la manière que
voici :
6.1. Délimitation temporelle
Dans la délimitation temporelle, notre travail dans le temps, nous avons collecté les
données durant la période de l’année 2018 à l’année 2020. C’est ainsi que notre future
solution sera d’application tant que le système actuel restera inchangé.
6.2. Délimitation spatiale
Notre étude a pour champs d’investigation au centre des impôts synthétique située
dans commune : Kampemba, Q : bel-air, AV : lilas, n°2.
7. SUBDIVISION DU TRAVAIL
Ce travail s’articule autour de quatre chapitres hormis l’introduction générale et la conclusion
à savoir :
Le premier chapitre de notre étude se nomme Définitions des concepts de base et
considérations théoriques
Le deuxième chapitre de notre étude porte sur la description du traitement au sein du
domaine, donc une étude minutieuse de l’historique, la situation géographique ainsi l’étude du
système existant.
Le troisième chapitre consacre ses grandes lignes à la conception d’un nouveau
système informatique.
Le quatrième chapitre de notre étude porte sur l’implémentation, c'est-à-dire la mise
en œuvre du système, ces chapitres pourront finalement aborder à toute notre problématique.

15. 15
CONCLUSION PARTIELLE
En effet dans cette partie introductive, Nous étions en train de présenté notre sujet de
recherche, et nous nous sommes basé beaucoup plus sur la solution que nous allons apporter
dans l’entreprise, dans les lignes qui suivent nous allons présenter le champ d’étude et faire
son étude systématique.

16. 16
CHAPITRE I. DEFINITION DES CONCEPTS ET CONSIDERATIONS
THEORIQUES
INTRODUCTION
Dans cette partie du travail nous allons définir quelques concepts clés de notre travail et
aussi pour n’est pas épargner les règles du domaine qui s’impose nous allons définir quelques
concepts informatiques et afin chuter par le langage de modélisation qui intéresse notre
travail.
1.1 DEFINITION DES COCEPTS
1.1.1. CONCEPTS LIE AU DOMAINE D’ETUDE
 IMPOTS :
 CONTRIBUABLES :
 BENEFICE :
 Conception : Est l’ensemble des travaux préliminaires qui facilitent le
service dans un lieu.16
 Site Web : C’est un logiciel applicatif hébergé sur un serveur accessible via
un navigateur web.17
1.1.2. CONCEPTS INFORMATIQUES
Cette sous-section nous permettra de définir les concepts informatiques qui seront
Courant au cours de notre développement.
i. Php : Est un langage de script multi plate-forme, embarqué dans des documents. 18
HTML ;
ii. SGBD : Est un système de gestion de base de données qui peut être perçu comme
un ensemble de logiciels. Il permet aux utilisateurs d’insérer, de modifier, et de
rechercher efficacement de données spécifiques par les multiutilisateurs ; 19
16 Définition Encyclopédique
17 Définition Encyclopédique
18 cours
19 cours

17. 17
iii. Mysql : Est un système de gestion de base de données relationnelle basée sur le
langage d’interrogation SQL (Structure Query Language) ;20
iv. Url (Uniform Resource Locator) : pointe sur une ressource. C’est une chaine de
caractères permettant d’indiquer un protocole de communication et un
emplacement pour toute ressource du web ; 21
v. Serveur web : un serveur web est un hôte sur lequel fonctionne un serveur http
(ou serveur web). Un serveur web héberge les ressources qu’il dessert ;22
vi. Moteur de recherche : un moteur de recherche est une application web
permettant de retrouver des ressources (pages web, image, fichiers,…) associés à
des mots quelconques ; 23
vii. Navigateur web : un navigateur web est un hôte sur lequel fonctionne un
programme serveur. Il est en attente des requêtes d’un programme client sur les
documents proposés par différents sites ; tels que (Mozilla, Firefox, internet
explore…) ; 24
viii. Page web : est un document destiné à être consulté avec un navigateur web,
une page web est toujours constituée d’une ressource centrale (généralement un
document HTML) et d’éventuelles liées automatiquement accessibles (par
exemple : des images…) ; 25
ix. Hébergeur : est une entité ayant pour vocation de mettre à la disposition
des internautes des sites web conçus et gérés par des tiers ; 26
20 Cours
21 cours
22 Cours
23 cours
24 cours
25 cours
26 cours

18. 18
1.2 CONSIDERATION THEORIQUE
1.2.1 LANGAGE DE MODELISATION
1.2.1.1. LE LANGAGE DE MODELISATION UML
Pour programmer une application, il ne convient pas de mettre l'accent que sur
l'écriture du code. Il faut d'abord organiser ses idées, les documenter, puis organiser la
réalisation en définissant les modules et étapes de la réalisation. C'est cette démarche
antérieure à l'écriture que l'on appelle modélisation, son produit est un modèle.
Cette modélisation nécessite l'utilisation d'un langage permettant la description du
système logiciel ainsi que sa compréhension par ses futurs utilisateurs. Pour ce faire, nous
choisissons UML (Unified Modeling Langage) comme langage de modélisation de notre
système, car il comble une lacune importante des technologies objets et parce que nous
sommes très familiers à ce langage.
Il permet d'exprimer et d'élaborer des modèles objet, indépendamment de tout langage
de programmation. De plus, grâce à sa notation graphique, il permet d'exprimer visuellement
une solution objet, ce qui facilite la comparaison et l'évaluation de solutions. Enfin, l'aspect
formel de sa notation limite les ambiguïtés et les incompréhensions.
UML 2.5 s’articule autour de 14 diagrammes. Ces derniers sont dépendants
hiérarchiquement et se complètent, de façon à permettre la modélisation d'un projet tout au
long de son cycle de vie.
A. Diagrammes structurels ou statiques
Les diagrammes structurels ou statiques (Structure Diagram) rassemblent :
 Diagramme de classes (Class diagram) : il représente les classes intervenant
dans le système.
 Diagramme d'objets (Object diagram) : il sert à représenter les instances de
classes (objets) utilisées dans le système.
 Diagramme de composants (Component diagram) : il permet de montrer les
composantsdu système d'un point de vue physique, tels qu'ils sont mis en œuvre
(fichiers, bibliothèques,bases de données…).
 Diagramme de déploiement (Deployment diagram) : il sert à représenter les
éléments matériels (ordinateurs, périphériques, réseaux, systèmes de stockage…)

19. 19
et la manière dont les composants du système sont répartis sur ces éléments
matériels et interagissent entre eux.
 Diagramme des paquetages (Package diagram) : un paquetage étant un
conteneur logique permettant de regrouper et d'organiser les éléments dans le
modèle UML, le diagramme de paquetage sert à représenter les dépendances
entre paquetages
 Diagramme de structure composite (Composite Structure Diagram) : depuis
UML 2.x, permet de décrire sous forme de boîte blanche les relations entre
composants d'une classe.
 Diagramme de profils (Profile diagram) : depuis UML 2.2, permet de
spécialiser, de personnaliser pour un domaine particulier un meta-modèle de
référence d'UML.
B. Diagrammes comportementaux
Les diagrammes comportementaux (Behavior Diagram) rassemblent :
 Diagramme des cas d'utilisation (use-cases ou Use Case Diagram) : il permet
d'identifier les possibilités d'interaction entre le système et les acteurs
(intervenants extérieurs au système), c'est-à-dire toutes les fonctionnalités que
doit fournir le système.
 Diagramme états-transitions (State Machine Diagram) : permet de décrire sous
forme de machine à états finis le comportement du système ou de ses
composants.
 Diagramme d'activité (Activity Diagram) : permet de décrire sous forme de
flux ou d'enchaînement d'activités le comportement du système ou de ses
composants.
C. Diagrammes d'interaction ou dynamiques
Les diagrammes d'interaction ou dynamiques (Interaction Diagram) rassemblent :
 Diagramme de séquence (Sequence Diagram) : représentation séquentielle du
déroulement des traitements et des interactions entre les éléments du système
et/ou de ses acteurs.
 Diagramme de communication (Communication Diagram) : depuis UML 2.x,
représentation simplifiée d'un diagramme de séquence se concentrant sur les
échanges de messages entre les objets.

20. 20
 Diagramme global d'interaction (Interaction Overview Diagram) : depuis
UML 2.x, permet de décrire les enchaînements possibles entre les scénarios
préalablement identifiés sous forme de diagrammes de séquences (variante du
diagramme d'activité).
 Diagramme de temps (Timing Diagram) : depuis UML 2.3, permet de décrire
les variations d'une donnée au cours du temps.
1.2.1.1. PROCESSUS DE DEVELOPPEMENT LOGICIEL
UML est un langage qui permet de représenter des modèles, mais il ne définit pas le
processus d'élaboration des modèles. Un processus de développement logiciel avec UML est
un ensemble d’étapes permettant de concevoir un logiciel à l’aide du formalisme UML. Il
existe plusieurs processus UML. Cependant, dans le cadre de la modélisation d'une
application informatique, les auteurs d'UML préconisent d'utiliser un processus :
- Piloté par les besoins des utilisateurs ;
- Centré sur l’architecture ;
- Itératif et incrémental
Exemple : UP, 2TUP, SCRUM, XP…
LE PROCESSUS UNIFIE (UP)
1. Présentation
Un processus définit une séquence d’étapes, partiellement ordonnées, qui concourent à
l’obtention d’un système logiciel ou à l’évolution d’un système existant. L’objet d’un
processus de développement est de produire des logiciels de qualité qui répondent aux
besoins de leurs utilisateurs dans des temps et des coûts prévisibles.
Plus simplement, un processus doit permettre de répondre à la question fondamentale :
« Qui fait quoi et quand ? ».
2. Les principes fondamentaux du processus unifié (UP)
Le Processus Unifié (UP, pour Unified Process) est un processus de développement
logiciel « itératif et incrémental, centré sur l’architecture, conduit par les cas
d’utilisation et piloté par les risques » :
– Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1
mois) qui aident à mieux suivre l’avancement global. À la fin de chaque itération, une
partie exécutable du système final est produite, de façon incrémentale.

21. 21
– Centré sur l’architecture : tout système complexe doit être décomposé en parties
modulaires afin de garantir une maintenance et une évolution facilitées. Cette
architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML et
pas seulement documentée en texte.
– Piloté par les risques : les risques majeurs du projet doivent être identifiés au plus tôt,
mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce cadre
déterminent l’ordre des itérations.
– Conduit par les cas d’utilisation : le projet est mené en tenant compte des besoins et
des exigences des utilisateurs. Les cas d’utilisation du futur système sont identifiés,
décrits avec précision et priorisés.
3. Les phases et les disciplines d’UP
La gestion d’un tel processus est organisée suivant les quatre phases suivantes :
initialisation, élaboration, construction et transition.
La phase d’initialisation conduit à définir la « vision » du projet, sa portée, sa
faisabilité, son business case, afin de pouvoir décider au mieux de sa poursuite ou de
son arrêt.
La phase d’élaboration poursuit trois objectifs principaux en parallèle :
- Identifier et décrire la majeure partie des besoins des utilisateurs,
- Construire (et pas seulement décrire dans un document !) l’architecture de base du
système,
- Lever les risques majeurs du projet.
La phase de construction consiste surtout à concevoir et implémenter l’ensemble des
éléments opérationnels (autres que ceux de l’architecture de base). C’est la phase la plus
consommatrice en ressources et en effort.
Enfin, la phase de transition permet de faire passer le système informatique des mains
des développeurs à celles des utilisateurs finaux. Les mots-clés sont : conversion des
données, formation des utilisateurs, déploiement, béta-tests.
Chaque phase est elle-même décomposée séquentiellement en itérations limitées dans le
temps (entre 2 et 4 semaines). Le résultat de chacune d’elles est un système testé,
intégré et exécutable. L’approche itérative est fondée sur la croissance et l’affinement
successifs d’un système par le biais d’itérations multiples, feedback et adaptation

22. 22
cycliques étant les moteurs principaux permettant de converger vers un système
satisfaisant. Le système croît avec le temps de façon incrémentale, itération par
itération, et c’est pourquoi cette méthode porte également le nom de développement
itératif et incrémental. Il s’agit là du principe le plus important du Processus Unifié.
Les activités de développement sont définies par cinq disciplines fondamentales qui
décrivent la capture des exigences, l’analyse et la conception, l’implémentation, le
test et le déploiement. La modélisation métier est une discipline amont optionnelle et
transverse aux projets.
UP doit donc être compris comme une trame commune des meilleures pratiques de
développement, et non comme l’ultime tentative d’élaborer un processus universel.
CHAPITRE II. PRESENTATION DE L’ORGANISATION ET DESCRIPTION DES
TRAITEMENTS
Dans ce chapitre, nous allons devoir faire une étude sur le système existant, nous allons
commencer par la présentation de l’organisation où nous allons donner la situation
géographique du Centre des impôts synthétique, l’historique ainsi que le fonctionnement et
l’organisation de la CIS.
 Ensuite, nous allons faire la délimitation du système à l’étude grâce au
diagramme de contexte, le déroulement des processus, résumer les besoins
des utilisateurs par le diagramme de cas d’utilisation, résumer les processus
avec le diagramme d’activités.
 Enfin de faire un diagnostic sur le système existant en donnant les points forts
du système, mes points faibles et la proposition des solutions nouvelles.
II.1.PRESENTATION DE L’ORGANISATION
II.1.1. SITUATION GEOGRAPHIQUE
Le siège social de la Direction Générale des Impôt se situe dans la ville province de
Kinshasa au N° de l’avenue, notre domaine d’étude se délimite sur l’antenne provinciale du
Haut-Katanga au croisement des avenues Sendwe et Tabora au n° dans le quartier Makutano
de la commune de Lubumbashi dans le centre-ville de Lubumbashi.

23. 23
II.1.2. HISTORIQUE
La Direction Générale des Impôts est née à l'époque coloniale sous la
dénomination « Direction Générale des Impôts et Taxes du Congo Belge », la gestion de cette
direction et celles du trésor de la comptabilité, de la gestion de la dette publique, de
l'informatique et de la douane ont fonction jusque peu après l'accession de notre pays à
l'indépendance, comme des directions dépendant du secrétariat général aux finances.
La Direction Générale des Impôts dans son ancienne formule, occupait des travaux
d'assiettes, du recouvrement et de contrôle de toutes personnes physiques et morales
éparpillées sur toute l'étendue de la République Démocratique du Congo. A l’intérieur du
pays, plus précisément dans les provinces, les prérogatives dévolues à la direction générale
des impôts étaient assurées par une division provinciale des impôts.
La direction des impôts et taxes n'échappera pas à cette logique liée aux impératifs
nouveaux découlant de l'évolution de la matière fiscale. C'est ce qui explique les différentes
stratégies de réforme qui ont conduit aux nombreuses restructurations de cette direction.
Trois périodes marquent l'histoire de l'administration fiscale de trois pays à savoir :
 La période avant 1988, sous l'appellation « direction des impôts et taxes » ;
 La période avant 1988 à 2003, « Direction Générale des Contributions » ;
 La période de 2003 à nos jours, « Direction Générale des Impôts » par le décret
n°017/2003 du 02 mars 2003. Cette dernière restructuration répond ainsi au souci de
mieux justifier la conception liée au caractère même de la notion de « contribution » jugée
moins contraignant.
II.3 Fondement juridique
La base juridique de la création de la direction générale des impôts est le décret
n°017/2003 du 02 mars complété et modifié par le décret n°04/099 du 30 décembre 2004 ces
textes de lois remplacent et abrogent les ordonnances n°88/039 du 10 mars 1988 et n°89/099
du 12 mai 1989 portant création de la DGI.

24. 24
Toutes les missions assignées à l'ancienne Direction Générale des Contributions
(DGC) sont reprises par la Direction Générale des Impôts. Cependant l'organisation de type
fonctionnel qui était mise sous la DGC a changé au profit d'une organisation par type des
contribuables. Celle-ci est fondée sur une stratégie en vertu de laquelle les services de
l'administration centrale se consacrent aux missions de pilotage de conception et d'animation
pendant que la gestion des contribuables par importances des enjeux fiscaux est confiée à des
services extérieurs appelés « services opérationnels ».
Son personnel est régie par le décret n° 018/2003 du 02 mars 2003 qui remplace et
abroge ordonnance n°89/099 du 12 mai 1989 portant sur le règlement d'administration relatif
au du personnel de carrière de la DGI.
Outre, les dispositions au recrutement, période probatoire, positions administratives,
régime disciplinaire, cotisation, avancement en grade, cessations définitives de services
reprises dans les anciennes dispositions, le décret n°018 du 02 mars 2003 innove par la mise
en place d'un corps des inspecteurs.
3. MISSION ET OBJECTIF
3.1 MISSION
Au terme de l'article 2 du décret n°017/2003 du 02 mars 2003 la Direction Générale
des Impôts est l'organe administratif qui a la vocation d'exercer, dans le cadre des lois
et règlement, les missions et prérogatives en matière fiscale ; celles-ci comprenant l'assiette, le
recouvrement, le contrôle et le contentieux des impôts, taxes et prélèvement à caractère fiscal.
Celle-ci comprend entre autres, celles relatives à l'assiette, le contrôle, le recouvrement et le
contentieux des impôts, taxes redevance et prélèvements à caractère fiscal. A ce titre, elle est
chargée d'étudier et de soumettre à l'autorité compétente, les projets de lois, de décrets arrêtés
et instructions en matière fiscale.
De ce fait, elle constitue l'instance par excellence, de consultation pour tout texte ou
toute convention à incidence fiscale ou tout agrément d'un projet d'investissement à un régime
fiscal dérogation.
La Direction Générale des Impôts (DGI) exerce ses compétences de manière
exclusive, sur toute l'étendue du territoire national. Son rôle étant de collecter l'impôt en
faveur de l'Etat, la DGI met à disposition de son personnel une allocation budgétaire au moins

25. 25
égales à 5% des recettes assignées ainsi celle de 50% des pénalités fiscales recouvrées en vue
de la motiver, elle bénéficie également en sus des crédits budgétaires lui allouer à cet effet,
d'une quotité de 10% des pénalités recouvrées pour ses dépenses d'investissement.
Son objectif principal consiste en la maximisation des recettes pour le comptes du
trésor public par la fiscalisation des opérations économiques et autres contribuables, des
réalisations revêtent donc un caractère socio-économique très considérable, car les recettes
aussi générées accordent à l'Etat congolais, les moyens de sa subsistance qui lui permettent
d'exercer ses prérogatives régulières en matière financier et budgétaire.
4. FONCTIONNEMENT ET ORGANISATION
Ici nous allons expliquer le fonctionnement de notre domaine de recherche c’est-à-dire
le fonctionnement de la DGI/Haut-Katanga.
NB : le régime de fiscal congolais est déclaratif c’est-à-dire il y a une déclaration, on donne
la liberté au contribuable de déclarer librement sa redevance, après la déclaration le
contribuable dépose sa déclaration au bureau accueil et information.
Le bureau d’accueil est subdivise en deux cellules à savoir :
 cellule accueil et information
 cellule liaison
a. cellule d’accueil et information
Cette cellule a pour mission :
 de réceptionner la déclaration de contribuables et diverses correspondances en
d’autre terme la cellule d’accueil perçoit aussi d’autres correspondances
 cette cellule effectuer aussi le traitement de déclaration
Traitement de déclaration à la cellule d’accueil et information se fait comme suite :
Il est demandé à la cellule d’effectuer l’étude formelle de la déclaration du
contribuable c’est-à-dire contrôlé si la déclaration est remplie correctement ; cette
étude formelle s’effectue avant la réception de la déclaration ; après avoir fait cette

26. 26
vérification de la déclaration la cellule d’accueil et information a l’obligation de
réceptionner la déclaration.
Elle est réceptionnée par l’apposition d’un sceau qui contient la date, le nom de la
personne qui a réceptionné, en suite on demande au contribuable de déposer sa
déclaration au bureau de recouvrement précisément au C.T.R.S (centre de traitement
de recouvrement et saisie).
b. Cellule liaison
Cette cellule a pour mission de lier le contribuable a l’administration en fin de donner
plusieurs information au nouveau contribuable et a comme rôle de distribuer
différentes correspondances aux personnes approprier.
c. Bureau C.T.R.S
C’est ce bureau qui imprime et qui donne le récépissé au contribuable et ce dernier se
rend à la banque
NB : on se bien intéressé plus a ce bureaux car c’est là que se fait le recouvrement de
redevance
5. Présentation de l’organigramme hiérarchique

27. 27
ORGANIGRAMME DU CENTRE DES IMPOTS SYNTHETIQUE
1 Bureau appoint et
contentieux
Bureau de recensement Bureau informatique Bureau accueil
vulgarisation
Bureau recouvrement
Chef de centre
Secrétaire du chef de centre
Cellule
taxation
Cellule
de
recherché
recensement
Cellule
appoint
Cellule
contentieux
Cellule
d’informatique
Cellule
de
Liaison
Cellule
recettes
et
statistique
Cellule
de
droit
courant
Cellule
documentation
Cellule
dévaluation
Figure 1 : Organigramme du domaine

28. 28
II.2.DELIMITATION DU PERIMETRE D’ETUDE
Notre périmètre d’étude est la direction générale des impôts, de la commune kampeba au
quartier bel air.
II.2.1. CIRCULATION DE L’INFORMATION DU METIER
Voici comment s’effectue la déclaration de l’impôt à la Direction générale d’Impôt :
en premier lieu, le contribuable à son arrivé, se dirige à la réception pour demander la
déclaration en s’expliquant, si on l’autorise la déclaration, cette dernière lui remet une fiche
de déclaration qu’il devra remplir. Une fois qu’il a fini de remplir la fiche de déclaration, il la
dépose au bureau d’accueil et information qui va vérifier les informations suivantes : le nom
du contribuable, le numéro d’impôt, type d’impôt et autres informations supplémentaires…
Après ces opérations, le contribuable se dirige au bureau de traitements pour payer son impôt.
Le guichet vérifie la somme et établi un bordereau si la somme correspond au montant
indiqué sur le récépissé et enregistrer le paiement et valide le récépissé, en suite, il lui remet
un bordereau comme preuve de paiement.
II.2.2. MODELISATION DU METIER
La modélisation du métier est une activité dont l’objectif est de construire un modèle
qui décrit les aspects statiques et dynamiques du cas d’étude, en ignorant les détails de
l’implémentation technique et informatique.27 Nous pouvons aussi dire que ça vise à mieux
connaitre le fonctionnement et les règles qui régissent le système organisationnel dans lequel
on envisage d’implanter un nouveau système informatisé.
27 ERNETS NGONGO ; Cours de système informatique ; L2 INFO/l’shi ; inédit

29. 29
1) RECENSEMENT DES ACTEURS
A ce stade, nous allons répertorier les acteurs de notre domaine d’études et décrire le
rôle qu’ils jouent dans le système de déclaration d’impôts pour expliciter, un acteur est une
personne physique ou morale qui joue un rôle dans les domaines d’étude. Nous avons recensé
quatre acteurs dans le tableau ci-dessous :
N° Acteur Rôle ou fonction
1 Contribuable Personne physique ou morale qui a
l’obligation de payer l’impôt
2 Réception La personne qui reçoit le contribuable.
3 Bureau d’accueil Le bureau qui s’occupe de la déclaration
des impôts des contribuables
5 Bureau de traitement et
recouvrement
L’instance de la DGI qui se charge de
donner le récépissé au contribuable et
enregistrer le paiement de l’impôt
2) DIAGRAMME DE CONTEXTE
Le diagramme de contexte est le schéma qui nous présente le système comme une boite
noire tout en délimitant son périmètre et aussi d’avoir une vision globale des interactions entre
les acteurs et leurs liens avec l’environnement extérieur, afin de voir d’une manière plus claire
tous les acteurs qui interagissent avec ce dernier. Il donne aussi la première vue formelle,
voici comment il se présente.
Figure 2 : Recensement des acteurs du système

30. 30
Contribuable
Reception
Bureau d'accueil
Bureau de traitement
GESTION DU CONTRIBUABLE
1. ANALYSE FONCTIONNELLE DU METIER
Elle permet d’avoir une bonne compréhension des besoins des utilisateurs, ces besoins
constituent les spécifications qui nous permettrons de bien concevoir la solution nouvelle.
Analyser un métier consiste aussi à ressortir les différents processus et diagramme qu’un
métier peut renfermer entre autres, le cas d’utilisation, les intervenants d’un métier ainsi
que les activités et contextes.
A. Recensement des cas d’utilisations
1. Demander déclaration
2. Enregistre Fiche
3. Vérifier Infos
4. Enregistrer Infos
5. Enregistrer payement
6. Livrer bordereau
B. Attribution de cas d’utilisation
1. CONTRIBUABLE
 Demander déclaration
2. RECEPTION
 Remettre fiche
3. BUREAU D’ACCUEIL
Figure 3 : Diagramme de contexte métier

31. 31
 Vérifier infos
 Enregistrer Fiche
4. BUREAU DE TRAITEMENT
 Enregistrer payement
 Livrer bordereau
C. Diagramme de cas d’utilisation métier
Le diagramme de cas d’utilisation montre les interactions entre les acteurs et le
système à étudier. Il représente la structure des grandes fonctionnalités nécessaires aux
utilisateurs du système. Ainsi pour représenter les grandes fonctionnalités du système, voici le
schéma ci-dessous.
a) Les acteurs
 Contribuable
 Réception
 Bureau d’accueil
 Bureau de traitement et Recouvrement
b) Les cas d’utilisations
 Demander déclaration
 Enregistre Fiche
 Vérifier Infos
 Enregistrer Infos
 Enregistrer payement
 Livrer bordereau

32. 32
Contribuable
Bureau d'accueil
bureau de traitement
Réception
Démander declaration
Vérifier Infos
Livrer Bordereau
Enregistrer Fiche
Remettre Fiche
Enregistrer Payement
2. ANALYSE FORMELLE DU METIER
La description formelle du métier, nous permet de
bien comprendre le déroulement des activités au sein du domaine d’étude. Pour mieux réaliser
cela, nous allons nous servir du diagramme d’activité proposé par UML, il montre
l’enchainement des actions au sein d’une activité.
Figure 4 : Diagramme de cas d’utilisation métier

33. 33
a. DIAGRAMME D’ACTIVITE
Ce diagramme donne une vision des enchaînements
des activités propres à une opération ou à un cas d’utilisation. Il permet aussi de représenter
les flots de contrôle et les flots de données.28
CONTRIBUABLE RECEPTION BUREAU D'ACCUEIL BUREAU DE TRAITEMENTS
Démander déclaration
Remplir Fiche
Payer Impôt
Réméttre Fiche
Vérifier Information
Etablir Bordereau
Remettre Boredereau
Autorisé
Non Autorisé
II.3 Etude des documents
a. Etude des documents
28 Ass. MUCHAPA TUJENGE P. Cours introduction à uml, UPL, 2014, P, 10, Inédit
Figure 5 : Diagramme d’activité

34. 34
 Fiche recensement : C’est un document permettant le recensement du contribuable et
voici les informations u afférents.
 Nom
 Post nom
 Prénom
 Profession
 Lieu et date naissance
 Etat civile
 Téléphone
 Type de personne
 Récépissé :
 Numéro
 Nature-import
 Moment
 Talk
 Déclaration Impôt :
 Nom
 Téléphone
 Numéro récépissé
 Email
 Date déclaration
 Exercice fiscale
 Signature percepteur
 Récépissé
 Téléphone
 Numéro récépissé
 Email
 Date déclaration
 Montant
 Motif
 Fiche de perception physique
 Numéro perception
 Nom

35. 35
 Post nom
 Prénom
 Téléphone
 Montant
 Date
b. Modèle du domaine métier
Redevable
Num impot
Raison_soc
sigle
adresse_post
fax
email
adresse_phys
Déclaration
Num _dec
Date_dec
Exercice_fisc
Mode_paie
Quitance
Num_quit
Date_quit
motif
Effectuer
1
1..*
Appartenir
1
1..*
1..*
1..*
Figurer
Chiffreaf
Taux
Activité
Code_active
Nature
Figure 6 : Modèle du domaine métier

36. 36
II.4 DIAGNOSTIC DE L’EXISTANT
Ce point a pour but d’étudier le système de perception d’impôt traditionnelle à la
direction générale des impôts dans le but de donner les points positifs ainsi que les points
négatifs de ce dit système.
1. POINTS FORTS
Ici nous allons ressortir les points positifs qu’à l’entreprise, qui est :
 Des personnes compétentes en matière de fiscalités ;
 Un bon schéma de circulation des informations métier;
 Une bonne gestion des dossiers des contribuables ;
 Une bonne répartition des tâches entre bureaux ;
 Un bon travail d’équipe.
2. POINTS FAIBLES
C’est par notre curiosité que nous avons constaté quelques éléments négatifs, que
voici :
 Conservation des données su papiers avec risque de les égarer ;
 lenteur et l’attroupement de contribuables au même moment au bureau
d’accueil et information ;
 Recherche difficiles des informations antérieures dans beaucoup des papiers ;
 Absence du partage simultané des informations dans l’entreprise ;
 Perte des temps dans l’élaboration des rapports.
II.5 ETUDE DES SOLUTIONS NOUVELLES
A l’heure actuelle, la gestion manuelle de recouvrement n’est plus à désirer vu les
diverses Inconvénients qu’elle présente. Alors l’informatique via ses innovations se voue au
traitement automatique de l’information et allège les tâches de gestion.
Pour les problèmes dans la gestion telle que précité ci-haut, nous allons mettre en
place un site web qui permettra d’enregistrer, modifier et mettre en ligne les informations en

37. 37
rapport les contribuables qui pourra résoudre le problème de lenteur et de l’attroupement au
sein de la direction générale des impôts bel air.
CONCLUSION PARTIELLE
Dans ce chapitre il a été question de faire l’étude préalable du système et nous avons
présenté notre domaine, Par la suite, nous avons regroupé les besoins des utilisateurs sur base
des diagrammes de cas d’utilisation métier, d’activité et modèle du domaine.

38. 38
CHAPITRE III. CONCEPTION DU NOUVEAU SYSTEME INFORMATIQUE
Dans cette partie, il sera question d’exprimer en premier lieu les besoins des
utilisateurs afin de déterminer les fonctionnalités qui doivent être dotées au système logiciel
pour satisfaire ces besoins. Ensuite, nous allons aborder l’analyse et la conception qui
représentent les étapes les plus importantes pour le développement de notre projet.
I.1. Identification des besoins et spécification des fonctionnalités
Le besoin exprimé par notre champ d’étude est de mettre un site web de gestion du
contribuable. Ainsi, l’accession aux données soit facile dans cette entité.
1. Exigences fonctionnelles
La spécification fonctionnelle décrit les fonctionnalités principales de l’application à
créer et qui doivent répondre aux besoins de l’utilisateur29. Les fonctionnalités à doter à notre
système logiciel sont :
- L’envoie d’une demande de déclaration;
- La vérification de la demande;
- L’enregistrement d’un payement ;
- La gestion d’accès au système.
2. Exigences non fonctionnelles
Le système logiciel sera également doter des fonctionnalités techniques suivantes :
- Formulaires simples à manipuler ;
- Une ergonomie sobre et efficace : la mise en page du système doit faciliter au
maximum la démarche à l’aide d’une présentation claire et intuitive. Elle ne
doit pas demander un effort intellectuel important et non souhaité.
- La performance : à travers ses fonctionnalités, le système logiciel doit
répondre à toutes les exigences des utilisateurs d'une manière optimale ;
- L’extensibilité (maintenance) : le système logiciel doit se prêter facilement à
sa maintenance, c’est-à-dire à une modification ou à une extension des
fonctions qui lui sont demandées ;
- L’intégrité : le système logiciel doit protéger son code et ses données contre
des accès non autorisés ;
29 ASS HERNEST NGONGO ; « cours de conception L2 ig » ; isp ; 2019 ; Inedit

39. 39
- La facilité d’emploi : le système logiciel doit être facile à apprendre, à
utiliser, à interpréter des erreurs et à se rattraper en cas d’erreur d’utilisation ;
- La fiabilité : les accès au système logiciel doivent être extrêmement sûrs et
sécurisés ;
- La confidentialité : les informations concernant le propriétaire ne doivent pas
être divulguées ;
3. Identification et représentation des besoins
a. Délimitation du périmètre
Dans cette étude, nous allons nous atteler sur le système que voici :
DGI_CONTRIBUABLE.
b. Recensement des acteurs
Un acteur représente l’abstraction d’un rôle joué par des entités externes
(utilisateurs, dispositif matériel ou autre système) qui interagissent directement avec le
système étudié30.
Nous signalons que les acteurs sont toujours externes au système même s’ils sont
internes à l’organisation. Ainsi donc nous recensons les acteurs système suivants :
N° ACTEUR ROLE
1 Contribuable La personne d’impôt qui demande une déclaration
2 Bureau traitement Bureau chargé de gérer le payement d’impôt
3 Administrateur La personne ayant en charge le bon fonctionnement du
système.
30 Roques. P, Vallée. F. UML2 en action. Eyrolles, Paris, P.51
Figure 7 : Recensement des acteurs du nouveau système

40. 40
c. Le diagramme de contexte
Le diagramme de contexte est un outil nous permettant d’avoir une vision globale des
interactions entre les activités et les liens vis-à-vis de l’extérieur. Il permet également de bien
délimiter le champ d’étude.
Nous représentons ci-dessous le diagramme de contexte du nouveau système.
Contribuable
Bureau de Traitement
Administrateur
DGI_CONTRIBUABLE.COM
Figure 8 : Diagramme de contexte du nouveau système

41. 41
d. Identification des cas d’utilisation
Les principaux cas d’utilisation mis en évidence à travers les exigences fonctionnelles
sont les suivants :
- Demander une déclaration;
- Vérification Demande ;
- Enregistrer un payement ;
- Créer Utilisateur ;
- S’authentifier.
Nous présentons ci-dessous le diagramme de cas d’utilisation système.
Contribuable
Bureau de traitement
Administrateur
Enregistrer Payement
Gérer utilisateur
S'authentifier
«include»
«include»
«include»
Vérifier Démande
Demander déclaration
Figure 9 : Diagramme de cas d’utilisation

42. 42
e. Classification des cas d’utilisation par priorité et risque
Cas d’utilisation Priorité Risque Itération#
Demander déclaration Moyenne Bas 1
Vérifier Demande Haute Moyen 2
Enregistrer payement Haute Haut 3
Gérer Utilisateur Haute Bas 4
S’authentifier Haute Bas 5
Figure 10 : Tableau de priorité et risque

43. 43
f. La description textuelle des cas d’utilisations
Le diagramme de cas d’utilisation décrit les grandes fonctions du système de point de
vue des acteurs mais n’expose pas de façon détaillée le dialogue entre les acteurs et les cas
d’utilisation qu’ils initient. Il faut donc décrire textuellement chaque cas d’utilisation.
Un cas d’utilisation décrit un ensemble de scénarios. Un scénario décrit une exécution
particulière d’un cas d’utilisation du début à la fin31. On peut distinguer plusieurs types de
scénarios :
- Nominaux : ils réalisent les post conditions du cas d’utilisation, d’une façon
naturelle et fréquente ;
- Alternatifs : ils remplissent les post conditions du cas d’utilisation, mais en
empruntant des voies détournées ou rares ;
- D’exceptions : ne réalisent pas les post conditions du cas d’utilisation.
Pour que l’analyse soit relative, nous allons étudier en détail chaque cas d’utilisation
système devenu une itération. Ainsi, nous aurons les itérations suivantes :
31 Martin Fowler et Kendall Scott, UML le tout en poche

44. 44
 Pour l’itération : Demander déclaration
Objectif : Permettre au contribuable d’introduire la demande d’une déclaration ;
Acteur principal : Contribuable ;
Acteur secondaire : -;
Précondition (s) :
- Le système soit lancé;
- Le contribuable saisi les informations puits envoi la demande.
Scénarios :
 Nominal :
- Le contribuable demande la fiche de déclaration
- Le contribuable saisi les infos le concernant
- Déposer fiche déclaration
 Alternatif : Néant
 Exception :
- Le système affiche un message d’erreur en cas de mauvaise manipulation
Post Condition : Demande déclaration déposée
Figure 11 : Description demander déclaration

45. 45
 Pour l’itération : Vérifier demande
Objectif : Le bureau de traitement vérifie la demande de déclaration.
Acteur principal : Bureau de traitement
Acteur secondaire : Néant
Précondition (s) : Demande déclaration déposée
Scénarios :
 Nominal :
- Le contribuable dépose la fiche de demande déclaration
- Le bureau de traitement analyse les infos sur la fiche de demande
- Le bureau de traitement s’authentifier
- Le bureau de déclaration vérifie la demande
 Alternatif : Néant.
 Exception : Néant.
Post Condition : Demande déclaration vérifié
Figure 12 : Description vérifier demande

46. 46
 Pour l’itération : Enregistrer paiement
Objectif : Permettre au bureau de traitement enregistrer le paiement effectué par le
contribuable
Acteur principal : Bureau de traitement
Acteur secondaire : Néant
Précondition (s) :
- Demande déclaration trouvé
- S’authentifier ;
Scénarios :
 Nominal :
- Le contribuable dépose l’argent au bureau de traitement
- Le bureau de traitement saisit les informations nécessaires au paiement et
valide
- Le système confirme la prise en charge du paiement
- Le système enregistre le paiement
 Alternatif :
- Le bureau de traitement modifie les informations de paiement
 Exception : Le système émet un message en cas d’erreurs de manipulation
Post Condition : Le paiement de la déclaration est effectué.
Figure 13 : Description Enregistrer paiement

47. 47
Pour l’itération : Gérer comptes utilisateurs
Objectif : Permettre à l’administrateur de gérer les utilisateurs du système
Acteur principal : Administrateur
Acteur secondaire : Néant
Précondition (s) : Le système soit lancé
Scénarios :
 Nominal :
- L’administrateur s’authentifie pour avoir une connexion à la base de
données
- Le système valide
- L’administrateur demande d’enregistrer un nouvel utilisateur
- Le système retourne une fenêtre d’enregistrement
- L’administrateur saisi les informations qui concerne l’utilisateur
- Le système enregistre un nouvel utilisateur
 Alternatif :
- Modifier un utilisateur
- Supprimer un utilisateur
- Rechercher un utilisateur.
 Exception : le système émet un message en cas d’erreurs de manipulation
Post Condition : L’administrateur du système gère l’utilisateur.
Figure 14 : Description gérer utilisateur

48. 48
 Pour l’itération : S’authentifier
Objectif : Permettre à l’utilisateur d’accéder au système.
Acteurs concernés : Bureau traitement, Administrateur
Acteur secondaire : Néant
Précondition (s) :
-Système démarré
Scénarios :
 Nominal :
- L’utilisateur démarre le système.
- Le système affiche la page d’authentification
- L’utilisateur saisit les informations qui concernent l’authentification et
valide
- Le système vérifie les informations, autorise ou refuse l’accès au système.
 Alternatif :
-Si les informations saisit son conforme à celles de la base de données, le
système autorise l’accès
-Si les informations ne sont pas conformes, le système refuse l’accès.s
 Exception : le système émet un message en cas d’erreur de manipulation
 Erreur :
-Erreurs constatés lors de la saisie des informations, le système affiche le
message d’erreur.
-L’utilisateur corrige les erreurs ;
Post Condition : Authentification réussie ou non
Figure 15 : Description s’authentifier

49. 49
4. Spécification détaillée des besoins
La description textuelle présente des désavantages puisqu’il est difficile de montrer
comment les enchainements se succèdent ou à quel moment les acteurs secondaires sont
sollicités. Il est donc nécessaire de compléter la description textuelle par un ou plusieurs
diagrammes dynamiques UML. Pour notre cas, nous allons le réaliser grâce au diagramme de
séquence « système ». Ce dernier représente graphiquement la chronologie des interactions
entre les acteurs et le système, vu comme boite noire dans le cadre du scénario nominal,
servant à développer en analyse les scénarios d’utilisation du système.
4.1 Concepts de base
4.1. Ligne de vie : Représente la délimitation du champ d’action d’un acteur ou
d’un objet. Elle est représentée par un rectangle auquel est accrochée une
ligne verticale en pointillé.
4.2. Message
Défini une communication particulière entre les lignes de vie. Il peut s’agir de la
création ou de la destruction d’un objet, de l’envoi d’un signal, l’invocation d’une opération,
etc. 32
Il existe deux types de messages :
 Les messages synchrones : Ces sont des messages qui nécessitent un déroulement
temporel. Dans ce cas l’émetteur reste en attente de la réponse à son message avant de
poursuivre ses actions. 33
 Les messages asynchrones : Ces sont des messages qui ne nécessitent pas un
déroulement temporel. Dans ce cas, l’émetteur n’attend pas la réponse à son message,
il poursuit l’exécution de ses opérations.34
Pour Demander déclaration :
32 ERNEST NGONGO, Cours de conception L1 IG, ISP, 2019,Inédit, P18
33 ERNEST NGONGO, Cours de conception L1 IG, ISP, 2019,Inédit, P19
34 Idem

50. 50
Contribuable
DGI_contribuable.Com
5: Déposer fiche declaration
OPT
ALT
1: Demander déclaration
3: Demande autorisé
4: Demande non autorisé
2: Remplir fiche
BREAK
Figure 16 : activité demander déclaration

51. 51
Pour Vérifier une demande :
Bureau traitement
DGI_contribuable.Com
7: Demande déclaration vérifié
LOOP
ALT
2: Formulaire
REF
S'authentifier
Nominal
3: Saisir numèro demande
5: Demande trouvé
6: Demande non trouvé
1: Lancer formulaire vérification
4: Valider
Figure 17 : activité vérifié demander

52. 52
Pour Enregistrer un paiement :
Bureau traitement
DGI_contribuable.Com
2: Formulaire
REF
S'authentifier
Nominal
LOOP
3: Saisir informations paiements
5: Paiement enregistrer
1: Lancer formulaire enregistrement
4: Enregistrer
Figure 18 : activité enregistrer demande

53. 53
Pour gérer les comptes des utilisateurs:
Administrateur
DGI_contribuable.Com
LOOP
REF
1: S'authentifier
Nominal
OPT
3: Interface d'enregistrement
5: Utilisateur enregistré
9: Utilisateur supprimé
7: Utilisateur modifié
8 : Supprimer utilisateur
2: Enregistrer un utilisateur
4: Saisir informations utilisataeur
6 : Modifiier utilisateur
8 : Supprimer utilisateur
Figure 19 : activité gérer utilisateur

54. 54
Pour s’authentifier :
Utilisateur
DGI_contribuable.Com
LOOP
1: Saisir Login ET Password
3: Login ou password invalide
Break
4: Page d'accueil
ALT
Source : Cours de conception l1 ig isp 2019
2: Valider
Figure 20 : activité s’authentifier

55. 55
I.2. PHASE D’ANALYSE
L’expression préliminaire des besoins donne lieu assez directement à une
modélisation par les cas d’utilisation (comme nous l’avons expliqué au niveau de la
phase précédente) et à une maquette d’IHM. Il s’agit là de descriptions fonctionnelles
qui vont nous servir en particulier pour les tests de recette à la fin du projet, mais aussi
de point d’entrée pour la description dynamique des scénarios d’exécution du futur
système.
En revanche, la conception objet demande principalement une description
structurelle, statique, du système à réaliser sous forme d’un ensemble de classes
logicielles, éventuellement regroupées en packages.
Les meilleures classes candidates sont celles issues d’une analyse du
domaine (souvent appelée aussi analyse métier), c’est-à-dire des concepts manipulés par
les experts du domaine. Pour passer en douceur à la conception, il nous faut encore
identifier les principales classes d’IHM ainsi que celles qui décrivent la cinématique de
l’application.
Dans cette phase d’analyse, nous allons établir tour à tour :
 Le modèle du domaine ;
 Le diagramme des classes participantes ;
 Le diagramme de navigation.
1. Le modèle du domaine
La phase d’analyse du domaine permet d’élaborer la première version du
diagramme de classes appelée modèle du domaine. Ce modèle doit définir les classes
qui modélisent les entités ou concepts présents dans le domaine (on utilise aussi le
terme de métier) de l’application. Il s’agit donc de produire un modèle des objets du
monde réel dans un domaine donné.35
Identification des concepts du domaine
L’étape typiquement orientée objet de l’analyse est la décomposition d’un
domaine d’intérêt en classes conceptuelles représentant les entités significatives de ce
domaine.
35 ERNEST NGONGO, COURS DE CONCEPTION, L2 IG, ISP, 2020

56. 56
Il s’agit simplement de créer une représentation visuelle des objets du monde réel
dans un domaine donné.
Comment identifier les concepts du domaine ? Plutôt que de partir à l’aveugle et
nous heurter à la taille du problème à résoudre, nous allons prendre les cas d’utilisation
un par un et nous poser pour chacun la question suivante : quels sont les concepts métier
qui participent à ce cas d’utilisation ?
Ainsi :
Pour demander une déclaration :
Demande_dec
-Numdec
-Date_dec
-Exerc_fisc
Activité
-Code_act
-Nature
-Chiffre_af
-Taux
1
Concerne
1..*
Envoyer
Contribuable
-Numimpot
-Rais_soc
-Sigle
-Adresse_post
-Fax
-Email
-Ad_physique
1..*
1
Figure 21 : modèle du domaine demander déclaration

57. 57
Pour vérifier demande :
Demande_dec
-Numdec
-Date_dec
-Exerc_fisc
Activité
-Code_act
-Nature
-Chiffre_af
-Taux
Concerne 1..*
1
Pour enregistrer paiement :
Demande_dec
-Numdec
-Date_dec
-Exerc_fisc
Paiement
-Num_paie
-Motif
-Montant
Concerne
Agent
-Mat_ag
-Nom_ag
-Postnom_ag
-Tel_ag
-Fonct_ag
1..* Effectuer 1..*
Effectuer
Date_paie
Nombre_paie
1..*
1
Figure 22 : modèle du domaine vérifier demande
Figure 23 : modèle du domaine enregistrer paiement

58. 58
2. Le diagramme de classes participantes
Un diagramme de classes participantes représente l’ensemble des classes qui
interagissent pour realiser un cas d’utilisation. Elle effectuent une fonction entre le cas
d’utilisation et le modèle du domaine c’est-à-dire, l’exécution d’un cas d’utilisation fait
interagir plusieurs objets(classes).
On distingue 3 types de classes participantes :
 Les classes de dialogue ;
 Les classes de contrôle ;
 Les classes d’entités.
Les classes de dialogue
Les « dialogues » représentent les moyens d’interaction avec le système.
Les classes de contrôle
Les « contrôles » contiennent la logique applicative.
Les classes d’entité
Les « entités » sont les objets métier manipulés.
Pour demander une déclaration :

59. 59
Entite_activite
-Codeact
-Nature
Entite_contrib
-Numipot
-Raisonsoc
-Sigle
-Adresse
Entite_demande
-Numdec
-Datedec
-exerfisc
Ctrl_demande
+Envoyer()
+Annuler()
Page_demande
+Envoyer()
+Annuler()
Figure 24 : Diagramme participante demander déclaration

60. 60
Pour vérifier une demande :
Entite_activite
-code_active
-Nature
Entite_demande
-Numdec
-Date_dec
-Exerc_fisc
Vérification_avancé
-Numimpot
+Rechercher()
+Annuler()
Vérification_rapide
-Numimpot
+Rechercher()
+Annuler()
Vérification
+Créer_user()
+Rechercher()
+Annuler()
Pour Enregistrer un paiement :
Demande_dec
-Numdec
-Date_dec
-Exerc_fisc
Entite_activite
-code_active
-Nature
Page_Enreg
-Infos_Recepteur()
+Enregistrer()
+Rechercher()
Ctrl_Enreg
+Enregistrer()
+Rechercher()
Figure 25 : Diagramme participante vérifier demande
Figure 26 : Diagramme participante enregistrer paiement

61. 61
3. Diagramme d’état de navigation
Le diagramme d’état de navigation est un ensemble des diagrammes dynamiques
représentant de manière formelle l’ensemble des chemins possibles entre les principaux
écrans proposés à l’utilisateur.
Le diagramme d’état de navigation représente ainsi un ajout important dans
l’arsenal des outils de modélisation du concepteur de site web ; il fournit la possibilité
de décrire précisément et exhaustivement les aspects dynamiques de l’interface
utilisateur. Diagramme d’états de navigation de l’internaute
«page»
Page d'accueil
internaute
«Frame»
Login
«page»
Demander un
objet
«frame»
Login
Détails
Connextion ok
Fin Traitement
«Frame»
Login
«Frame»
Login
«Frame»
Login
«page»
Fiche des objets
Figure 27 : Diagramme de navigation

62. 62
I.3. Phase de conception
À présent, nous allons attribuer des responsabilités précises de comportement aux
classes d’analyse identifiées au point précédent. Nous représenterons le résultat de cette
étude dans des diagrammes d’interactions UML. Nous construirons également une vue
statique complétée sous forme de diagrammes de classes de conception préliminaire,
indépendamment des choix technologiques qui seront effectués au chapitre suivant.
1. Diagramme d’interaction globale
Les diagrammes d’interaction permettent d’établir un lien entre les diagrammes de
cas d’utilisation et les diagrammes de classes : ils montrent comment des objets (i.e. des
instances de classes) communiquent pour réaliser une certaine fonctionnalité. Ils
apportent un aspect dynamique à la modélisation du système.
Ils sont représentés à l’aide soit des diagrammes de communication, soit encore à
l’aide des diagrammes de séquence détaillée. Pour ce qui nous concerne, nous le
représenterons à l’aide des diagrammes de séquence détaillée de quelques itérations.
 Pour l’itération : Demander déclaration
Contribuable
Lancez Formulaire
Saisir Infos
Find(id)
Demande sélectionnée
Message[If demande send]
Envoyer
Create()
Get(id)
Fiche demande
Form: Demande_dec Control: Demande_dec Entity: Demande_dec
Resultats

63. 63
 Pour l’itération : Vérifier demande
Bureau traitement
Chercher demande Chercher demande
Find
Resultats
Resultats
Create
Page précédente
Form: Demande Ctrl_Demande Entity: Demande Objet:map: <Objet>
Resultat recherche
Page suivante
Vérifier syntaxe
Vérifier Demande
Figure 28 : Diagramme d’interaction demander déclaration
Figure 29 : Diagramme d’interaction vérifier demande

64. 64
 Pour l’itération : Enregistrer paiement
Bureau traitement
Enregistrer paiement
Create
Form: Enreg_paie Ctrl_Enreg_paie Entity: Enreg_paie
Enregistrement Effectué
add (nouveau)
create
Infos paiement
Figure 30 : Diagramme d’interaction enregistrer paiement

65. 65
2. Diagramme de classe de conception
Il modélise toutes les classes nécessaires à l’implémentation de l’application. C’est
un diagramme plus général qui n’est pas seulement lié aux simples données, mais à
l’ensemble de classes de l’application.
Nous allons illustrer cela par les trois cas d’utilisation majeurs suivants :
 Pour l’itération : Demander déclaration
«Entité»
Entite_demande
-Numdec
-Datedec
-exerfisc
+Rechercher()
+Envoyer()
«Entité»
Entite_activite
-Codeact
-Nature
+Ajouter()
+Rechercher()
«Dialogue»
Page_demande
-Numdec
+Envoyer()
+Annuler()
«Controle»
Ctrl_demande
+Envoyer()
+Annuler()
«Dialogue»
Message d'erreur
«Resultat»
-Numdec
+Envoyer()
+Annuler()
«Dialogue»
Resultat demande
«Resultat»
-Numdec
+Page declaration()
+Page d'accueil()
«Entité»
Entite_contrib
-Numipot
-Raisonsoc
-Sigle
-Adresse
+Ajouterr()
+Rechercher()
Figure 31 : Diagramme de conception demander déclaration

66. 66
 Pour l’itération : Vérifier demande
«Dialogue»
Vérification_rapide
-Numimpot
+Rechercher()
+Annuler()
«Control»
Vérification
+Créer_user()
+Rechercher()
+Annuler()
«Entité»
Entite_demande
-Numdec
-Date_dec
-Exerc_fisc
+Créer_user()
+Rechercher()
+Annuler()
«Entité»
Entite_activite
-code_active
-Nature
+Ajouter()
+Rechercher()
«Dialogue»
Erreur Vérification
«Dialogue»
-Erreur : String
+Rechercher()
+Annuler()
«Dialogue»
Résultats Vérification
«Resultat»
-Numimpot : int
+Rechercher()
+Annuler()
«Dialogue»
Detail Page
«Resultat»
-detaill activité : string
+Enregistrer()
«Control»
Activité
«Dialogue»
Vérification_avancé
-Numimpot
+Rechercher()
+Annuler()
Figure 32 : Diagramme de conception vérifier demande

67. 67
 Pour l’itération : Enregistrer un paiement
«Entité»
Demande_dec
-Numdec
-Date_dec
-Exerc_fisc
+Ajouter()
+Rechercher()
«Entité»
Entite_Agent
-Mat_ag
-Nom_ag
-Postnom_ag
-Fonction_ag
-Tel_ag
+Enregistrer()
+Annuler()
«Entité»
Entite_activite
-code_active
-Nature
+Ajouter()
+Rechercher()
«Dialogue»
Page_Enreg
-Infos_Recepteur()
+Enregistrer()
+Rechercher()
«Control»
Ctrl_Enreg
+Enregistrer()
+Rechercher()
«Dialogue»
Erreur Manipulation
-Infos_Recepteur()
+Rechercher()
«Dialogue»
Message
«Dialogue»
+Enregistrer()
+Rechercher()
Figure 33 : Diagramme de conception enregistrer demande

68. 68
DIAGRAMME DE CONCEPTION GLOBALE
Demande_dec
-Numdec
-Date_dec
-Exerc_fisc
+Envoyer()
+Rechercher()
+Annuler()
Activité
-Code_act
-Nature
-Chiffre_af
-Taux
+Envoyer()
+Rechercher()
+Annuler()
1
Concerne
1..*
Envoyer
Contribuable
-Numimpot
-Rais_soc
-Sigle
-Adresse_post
-Fax
-Email
-Ad_physique
-Tel
+Ajouter()
+Annuler()
1..*
1
Paiement
-Num_p
-Motif_p
-Montant_p
+Enregistrer()
+Annuler()
+Imprimer()
Agent
-Mat_ag
-Nom_ag
-Postnom_ag
-Focntion_ag
-Tel_ag
+Enregistrer()
+Annuler()
1
Impliquer
1..*
Tenir
Tenir
-Date_P
-Nb_p
1..* 1..*
Figure 34 : Diagramme de Conception Globale

69. 69
3. Structuration en packages de classes
Démarche
Pour structurer notre modèle, nous allons organiser les classes et les regrouper en
ensembles cohérents.
Pour ce faire, nous utilisons une fois de plus le concept général d’UML, le package.
Les systèmes informatiques modernes sont organisés en couches horizontales, elles-
mêmes découpées en partitions verticales. Cette découpe est d’abord logique, puis
éventuellement physique en termes de machines.
Nous allons donc structurer les classes identifiées jusqu’à présent en trois couches
principales :
▪ Une couche Présentation, rassemblant toutes les classes dialogues ;
▪ Une couche Logique Applicative, rassemblant toutes les classes contrôles ;
▪ Une couche Logique Métier, rassemblant toutes les classes entités ;
L’architecture logique de notre étude de cas est ainsi représentée par un premier
diagramme de packages.
 Pour l’architecture logique
Présentation Logique Applicative Logique Métier
La structuration des couches Présentation et Logique Applicative peut s’effectuer
en tenant compte des cas d’utilisation. La structuration de la couche Logique Métier est
à la fois plus délicate et plus intéressante, car elle fait appel à deux principes
fondamentaux : cohérence et indépendance.

70. 70
Le premier principe consiste à regrouper les classes qui sont proches d’un point de
vue sémantique. Un critère intéressant consiste à évaluer les durées de vie des instances
et à rechercher l’homogénéité. Le deuxième principe s’efforce de minimiser les
relations entre packages, c’est-à-dire plus concrètement les relations entre classes de
packages différents.
Les packages ainsi constitués vérifient bien les principes de forte cohérence interne
et de faible couplage externe.
 Pour la logique Métier (IMPORT PAS ACCESS)
Déclaration
+Declaration
+activité
+Contribuable
+Paiement
Demande
+Bureau traitements
+Demande
«access»
I.4. Passage au modèle logique de données relationnel
Pour réaliser une base de données relationnelle, nous devons transformer le
diagramme de classe en un modèle logique relationnel. Nous avons le choix entre plusieurs
modèles logiques.
Nous avons choisi le modèle logique relationnel qui est fondé sur les solides bases
théoriques, car il propose des opérateurs issus des théories, des ensembles et aussi sa
représentation facile des données sous forme tabulaire36. Il est facile et on peut interroger la
base de données.
En plus, ce modèle a aussi un atout d’être pris en charge par la plupart des systèmes
de gestion de base de données (SGBD) actuels37.
36 Christian SOUTOU., UML2 pour les bases de données,Eyrolles, P. 103.
37 GARDARIN G., Bases de données : Objet et relationnel, Eyrolles, Paris 1999, P. 78.
Figure 35 : Diagramme de package

71. 71
Après transformation, nous sommes arrivés à ces tables ou relations suivantes :
Contribuable (Num_impot, Raison_soc, Sigle, Adresse_Post, Fax, Email,
Ad_physique, tel_cont, #Num_dec)
Agent ( Mat_ag, Nom_ag, Postnom_ag, Fonction__ag, postnom_ag, fonction_ag,
tel_ag)
Paiement (Num_p, motif_p, montant_p, #Num_dec)
Demande_dec (Num_dec, Date_dec, Exerc_fisc, #Num_impot)
Activité (Code_act, Nature)
Tenir (#Num_p, #Mat_ag, Date_p, Nb_p)

72. 72
CHAPITRE IV. REALISATION DU SYSTEME INFORMATIQUE
Introduction
Dans ce chapitre qui est notre phase finale, nous allons montrer le choix des outils de
développement, nous parlerons du choix du système de gestion de la base de données, du
choix de l’architecture logicielle ainsi que la présentation de l’application que nous avons
mise en place.
IV.1. Choix de l’architecture logicielle
Une architecture logicielle est une représentation abstraite d’un système exprimé
essentiellement à l’aide de composants logiciels en interaction via des connecteurs. C’est une
infrastructure composée de modules actifs, d’un mécanisme d’interaction entre ces modules
et d’un ensemble de règles qui gouvernent cette interaction.
Pour notre système, nous avons choisi le pattern architectural client web léger38. Le client
web très léger et universel est employé pour les applications destinées à internet, pour
lesquelles la configuration du client n’est pas maitrisable. Le client ne nécessite qu’un
navigateur web standard et le logique métier ainsi que la logique de présentation sont
intégralement exécutés sur le serveur.
Les composants majeurs du pattern architectural client web léger se trouvent sur le
serveur. Dans bien des sens, cette architecture est effectivement celle d’une application web
minimale.
 Le navigateur client est un navigateur HTML standard compatible avec les
formulaires et DHTML (Accepter et renvoyer des cookies).
 Le serveur web est le point d’accès principal pour tous les navigateurs client
 La page serveur est une page qui subit une forme de traitement du côté du serveur
 Le serveur d’applications est le principal exécuteur du logique métier du côté du
serveur
38 Pascal R.,UML 2 : Modéliser une application web 4 éme édition, éd.Eyrolles,Paris,2008,P/152

73. 73
 Le serveur de données permet de gérer la persistance des objets métier, par
exemple dans une base de données relationnelle. Si le système de persistance
choisi est une base de données relationnelle, une couche (souvent appelée DAO)
chargée d’effectuer le mapping objet/relationnel doit être ajoutée.
a. Architecture logicielle du système informatique
Une architecture logicielle est une représentation abstraite d’un système exprimée
essentiellement à l’aide de composants logiciels en interaction via des connecteurs. C’est une
infrastructure composée de modules actifs, d’un mécanisme d’interaction entre ces modules
actifs, d’un mécanisme d’interactions entre ces modules et d’un ensemble des règles qui
gouvernent cette interaction.
Pour notre système, nous avons choisi le pattern architectural client web léger.39 Le client web
très léger et universel est employé pour les applications destinées à internet, pour lesquelles la
configuration u client n’est pas maitrisable. Le client ne nécessite qu’un navigateur web
standard et le logique métier ainsi que la logique de présentation sont intégralement exécutés
sur le serveur.
Les composants majeurs du pattern architectural client web léger se trouvent sur le serveur.
Dans bien des sens, cette architecture est effectivement celle d’une application web minimale.
 Le navigateur client est un navigateur HTML standard compatible avec les
formulaires et DHTML (Accepter et renvoyer des cookies).
 Le serveur web est le point d’accès principal pour tous les navigateurs clients.
 La page serveur est une page qui subit une forme de traitement du côté du serveur.
 Le serveur d’applications est le principal exécuté du logique métier du côté du serveur.
 Le serveur de données permet de gérer la persistance des objets métier, par exemple
dans une base de données relationnelle, une couche (souvent appelée DAO) chargée
d’effectuer le mapping objet/relationnel doit être ajoutée.
b. Architecture technique (physique) du système informatique
39 Pascal R.UML 2 : Modéliser une application web,4 em Edition, éd Eyrolles,paris,2008,p.152

74. 74
L’architecture physique (également appelée architecture technique) décrit l’ensemble des
composants matériels supportant les applications. Voici sa présentation ci-dessous :
c. Vue de l’implémentation : Diagramme des composants
Dans l’approche par objets, l’architecture logicielle d’un système est construite par un
assemblage de composants liés par des interfaces fournies et des interfaces requises. Le
diagramme des composants décrit cette architecture.
1. Les composants
Un composant est une unité logicielle offrant des services au travers d’une ou de
plusieurs interfaces. C’est une boîte noire dont le contenu n’intéresse pas ses clients. Il est
totalement encapsulé : seules ses interfaces sont visibles.
Un composant peut dépendre d’autres composants pour réaliser ses opérations
internes. Il est alors le client de ces autres composants. Comme tout client d’un composant, il
n’en connaît pas la structure interne. Il ne dépend donc que de la ou des interfaces des
composants dont il est client. Ces interfaces sont appelées les interfaces requises du
composant client. Les interfaces qui décrivent les services offerts par un composant sont
appelées ses interfaces fournies.
Un composant est représenté dans un rectangle avec le stéréotype « component ». Ce
stéréotype peut être remplacé par le logo du composant.
2. Vue de déploiement : Diagramme de déploiement
IV.2. Choix des outils de développement
Les outils de développement sont des éléments qui nous permettent de mettre fin à notre
travail, nous parlerons à ce point
Dans ce paragraphe, nous présentons le cade de notre logiciel et les outils utilisés pour la
conception de notre application

75. 75
i. Système de gestion de base de données
Est un système de gestion de base de données relationnelle basée sur le langage
d’interrogation SQL ( Strucred Query Language). C’est un des logiciels open source de cette
catégorie des plus uytilisés.
Développé à partir d’un autre SGBD portant le nom de MSQL, il possède de nombreuses
qualités et notamment celles d’être portable, en ce sens qu’il s’exécute sur à peu près tous les
systèmes d’exploitation et tous les types de matériel.
ii. Atelier de génie logiciel
On désigne par AGL (Atelier de génie logiciel) un ensemble de programmes informatiques
permettant de produire des programmes de manière industrielle.40. Certaines AGL peuvent
aller jusqu'à la génération de code ou à l’inverser peuvent aller jusqu’à la génération de code
ou à l’inverse peuvent inclure des fonctionnalités de retro-ingénierie et donc analyser pour
modélisation les données contenus dans un programme.
Un AGL facilite la collaboration des différents programmeurs, ainsi que la maintenance
ultérieure des programmes en les incitants à partager les mêmes méthodes. Pour notre système
nous avons utilisé comme AGL star uml. Star uml est un logiciel de modélisation UML qui
est entré récemment dans le monde de l’open source, écrit en Delphi, il est modulaire et
propose plusieurs générations de code.
iii. Langage de programmation
La programmation web peut prendre différents formes. De la simple page statique à la page
dynamique avec connexion à une base de données. Cette programmation se fait du coté
serveur.
1. LE LANGAGE PHP
Le PHP est un langage de scripts multi plate formes, embarqués dans des documents HTML.
Plus simplement PHP offre un moyen de placer des instructions dans les documents HTML
en vue de créer des contenus dynamiques.
40 Wikipédia.org/wiki/atelier_de_logiciel.Consultele07/04/2015

76. 76
Ces instructions sont lues et analysées par le serveur web. Elles ne parviennent jamais
jusqu’au navigateur qui affiche la page. Le serveur web remplace le code PHP par le contenu
que le code avait pour but de générer.
C’est un langage qui est devenu de script coté serveur incorporable dans tout document
XHTML. il permet de créer des pages web dynamiques et interactives.
2. LE JAVASCRIPT
Le javaScript est un langage de script incorporé dans un document HTML. Historiquement il
s’agit même du premier langage de script pour le web. Ce langage HTML en permettant
d’exécuter des commandes du coté client, c’est-à-dire au niveau du navigateur et non du web.
Ainsi, le langage Javascipt est fortement dépendant du navigateur appelant la page web
laquelle le script est incorporé, mais en contrepartie il ne nécessite pas de compilateur,
contrairement au langage java avec lequel il a longtemps été confondu.
3. WAMPSERVER
WampServer est une plate-forme de développement web sous Windows. Il permet de
développer des applications web dynamiques à l’aide du serveur Apache, du langage de script
PHP et d’une base de données MYSQL. Il possède également PHPMyAdmin Pour gérer plus
facilement les bases de données.
IV.3. Présentation de l’application
Conclusion
CONCLUSION GENERALE

77. 77

78. 78