Plateforme de télé-procédure déclaration des impôts en

ligne

Ben Mohamed Imen

11 juin 2019
Introduction générale

Les systèmes e-gov concernent tout échange dématérialisé entre les autorités publiques
(ministères, services de l’état et organismes publics) et les usagers (entreprises, citoyens,
foyers fiscaux). Les gouvernement sont toujours en retards pour digitaliser ses systèmes d’in-
formations vue à sa sensibilité et sa criticité. D’ailleurs les gouvernement commencent par les
services les plus rentables en cas de passage au digital. Puisque les impôts sont parmi les plus
importantes ressources de financement pour chaque États, donc un système de déclaration
des impôts en ligne est primordiale pour une États qui veut migrer vers le monde de digital
et suivre la mode e-gov.
Notre problématique entre dans la plage des systèmes e-gov. Ces sont toutes procédures
gouvernementales qui se fait en ligne. L’émergence du gouvernement électronique tant sur le
plan pratique que conceptuel a été l’une des évolutions majeures de ces 10 dernières années
au sein de l’administration publique. Il a fait apparaître un nouveau vocabulaire, des modèles
théoriques et des liens entre les disciplines et entre la théorie et la pratique. L’e-gouvernement
est, par nature, un phénomène en constante évolution.
Dans le cadre de notre cursus d’ingénieur informatique spécialisé en génie logiciel, réalisé
au sein de l’université libre de Tunis, nous devons faire un stage professionnel, au sein d’une
entreprise au choix, qui dure entre quatre et six mois. L’objectif de ce stage est de réaliser
un projet qui validera nos connaissances et nos compétences et surtout de s’initier à la vie
professionnel en tant qu’un ingénieur informatique.
Pendant ce stage, nous avons passer une première période en faisant une étude sur le
métier du déclaration des impôts et les télé-procédures. Une fois que nous avons bien compris
la problématique, nous avons pu proposer une solution avec les méthodologies qui la mets en
évidence.
Nous avons modéliser notre solution selon des modèles formels qui assurent la clarté des
idées et la bonne compréhension, par suite la réutilisation de la solution entière ou bien de

1
quelques composants.
Nous avons implémenter notre proposition, afin de prouver sa faisabilité, et sa pertinence.
A la fin nous avons tester le fonctionnement de notre système, pour vérifier l’atteinte des
objectifs prévu.

2
Chapitre 1

Étude préalable

Dans ce premier chapitre de notre rapport, nous allons positionner le projet fait dans son
contexte général. Nous entamons dans un premier temps par la présentation l’université et
de l’organisme d’accueil. Nous allons définir dans un deuxième temps le contexte du projet,
qui nous permet de conclure la problématique pour laquelle nous proposons une solution. A
la fin de ce chapitre, nous présentons les méthodologies adoptée pour ce projet.

1.1 Présentation de l’Université

L’Université Libre de Tunis (ULT) [1], de parte sa large gamme de programmes d’études
aux trois cycles et ses activités diversifiées de recherche appliquée, a pour mission de former
aussi bien la relevé que les personnes en situation d’emploi, de rendre accessible la connais-
sance de pointe à tous les milieux sociaux et culturels et de servir la collectivité qui lui
exprime ses besoins.

3
 Figure 1.1 – Logo de l’Université Libre de Tunis [1]

1.2 Présentation de l’entreprise

Notre stage a eu lieu au sein de l’entreprise ArabSoft [2]. C’est une entreprise appartenant
au secteur privé. Elle a débuté son activité en 1985. Elle est composée de 130 employés
dont 115 concepteurs, notamment, développeurs et formateurs. Son capital social dépassera
les 500.000 TND. L’une des perspectives d’ArabSoft est l’investissement en recherche et
développement (15% du chiffre d’affaires). Ses investissements ont pour but d’atteindre des
solutions à forte valeur d’une part et de proposer des produits qui répondent bien aux besoins
du client tout en respectant des conditions de coût et de sécurité d’autre part.

1.2.1 Activités

Les activités de l’entreprise ArabSoft sont :

• l’étude, la conception et le développement de logiciels sectoriels spécifiques
• le développement de logiciels standards
• le déploiement de solutions en architecture client /serveur et n-tiers
• les formations sur les logiciels conçus et distribués.

1.2.2 Structure

Arab Soft est structurée de la manière suivante :

4
 Figure 1.2 – Structure de la société ArabSoft

1.2.3 Bonne Gouvernance Informatique

Depuis 2007 ArabSoft a crée une unité spécialisée dans les nouvelles technologies appelée
BGI (Bonne Gouvernance Informatique) avec un effectif de 56 ingénieurs. BGI est sous la
direction des projets, et regroupe les chefs des projets, les experts métiers et les ingénieurs
développeurs. Généralement les technologies les plus utilisés dans BGI sont Dot.net C# en
mode web et J2EE (ADF Oracle & Weblogic). Parmi les stratégies du ArabSoft et BGI, les
systèmes e-gov sont en vogue. C’est dans ce contexte que nous étions intégrés sous la direction
des projets avec les ingénieurs développeurs, afin d’élaborer la plateforme des télé-déclaration
des impôts durant notre période du stage qui dure quatre mois.

5
 Figure 1.3 – Logo BGI : bonne gouvernance informatique

1.3 Présentation de projet

En vue d’actualiser les orientations stratégiques et afin de répondre aux nouvelles aspira-
tions du citoyen en matière d’efficacité et d’ouverture de l’administration, et aux nouveaux
développements technologiques, les systèmes e-gov [3] permet une meilleure exploitation des
opportunités offertes par les TIC afin d’améliorer la qualité des prestations administratives
et renforcer la transparence et la participation citoyenne.

1.3.1 Contexte du projet : Télé-procédure

Les TIC nous aident à être plus réactifs grâce à l’intégration des technologies de l’informa-
tion dans les procédures, il est possible d’informer systématiquement l’usager de l’état de son
dossier, des actions qu’il doit entreprendre. Les TIC permettent de personnaliser d’avantage
la relation avec l’usager. "Personnaliser le service, c’est renverser la logique qui veut que le
demandeur s’adapte au découpage administratif" [4], et rendre à l’usager un service complet.
Les technologies de l’information peuvent nous aider dans ce sens, en accroissant l’efficacité
du transport d’informations entre services et avec les partenaires locaux de l’État.
Les TIC permettent de nouveaux accès à l’administration, plus souples, et plus simples. Avec
Internet, les services publics peuvent être plus facilement accessibles au plus grand nombre.
Un nouveau contact se crée entre les citoyens, les entreprises et les services publics, un nou-
veau accès à l’information et aux démarches administratives. Développer les services en ligne
de bout en bout, accessibles, multi-canaux et centrés autour des besoins du Citoyen, de l’En-
treprise et de l’Administration. L’usager est considéré comme le point central autour duquel

6
sont organisés les services et les procédures administratives.
L’accès aux services devrait être simplifié tout en faisant abstraction de la complexité de
l’organisation de l’administration et la répartition des activités. Il rassemble tous les services
et procédures nécessaires pour répondre à un événement de vie particulier. Un niveau in-
formationnel permettrait d’ores et déjà de s’affranchir de la complexité de l’administration.
Le processus de digitalisation et de personnalisation de ces services est à entamer l’ère des
télé-procédures.
Derrière ce terme barbare de "télé-procédure" se cachent des services qui pourraient bien
simplifier les relations avec les administrations. Selon la définition officielle, "la télé-procédure
concerne tout échange dématérialisé entre les autorités publiques (ministères, services de l’état
et organismes publics) et les usagers (entreprises, citoyens, foyers fiscaux)" [4]. Il s’agit en
fait de proposer une large gamme de services et d’informations dont chacun peut bénéficier
directement chez lui par l’intermédiaire d’internet. Une télé-procédure se définit comme un
échange relatif à une formalité administrative réalisé à distance (par Internet et à l’aide d’un
formulaire électronique) entre les services publics et ses usagers. Avec les télé-procédures,
l’enregistrement de la formalité et son traitement par les administrations s’effectuent entiére-
ment sous forme électronique. Le succès des télé-procédures est lié à la confiance des utilisa-
teurs. Aussi l’ensemble des télé-procédures proposé par les organismes publics sont sécurisées :
• sécurisation de l’accès au service (par mot de passe par exemple)
• cryptage des données envoyées
• protection des données personnelles
• reconnaissance légale de la signature électronique
La télé-procédure offre plusieurs avantages pour les entreprises puisqu’elles ne se déplacent
plus, elles s’affranchissent des horaires de l’administration et la procédure pour remplir les
formulaires électroniques est clairement expliquée étape par étape grâce à une aide en ligne.
Elles obtiennent immédiatement l’attestation correspondant à la formalité effectuée et surtout
elles sont informée de l’évolution de ses traitements si elles nécessitent un examen particulier.

1.3.2 Objectif de projet : Télé-déclaration

L’objectif de notre projet est d’élaborer une plateforme de télé-procédure qui permet aux
contribuables de déclarer ces impôts en ligne. Pour ce faire, nous avons fait une recherche

7
sur le processus métier en question pour bien comprendre le besoin.
La déclaration des impôts à travers le canal de l’Internet se développe dans le monde
entier. Pour les déclarations fiscales, les entreprises pourront procéder à la déclaration en
ligne auprès des services de la Direction Générale des impôts. La Télé-déclaration fiscale
est un service sécurisé qui permet aux contribuables d’effectuer à distance une liquidation
automatique et assistée de leurs impôts et taxes ainsi que le règlement électronique des
montants dus et le suivi de ses payements antérieurs. Cette application couvre par ses services
tous les contribuables patentés : Personnes Morale et Physique.
Ce service permet aux contribuables adhérents de liquider et déclarer leurs impôts à partir
de leur poste de travail en se connectant sur internet et en invoquant un service web. il doit
permettre aux contribuables de faire des :
• déclarations mensuelles d’impôts,
• déclarations annuelles ,
• dépôt des déclarations de l’impôt sur les sociétés,
• déclarations de l’avance due par les sociétés, les personnes et assimilées,
• déclarations de l’impôt sur le revenu des personnes physiques,
• déclarations de l’acompte provisionnel.
Par abuse de langage, nous appelons cette procédure télé-déclaration. Par contre c’est une
télé-liquidation. La différence est que cette dernière s’arrête au niveau de remplissage des
formulaires et validation du l’opération. La télé-déclaration englobe aussi le payement des
impôts en ligne. Pour notre projet, nous se focalisent sur la télé-liquidation des impôts.

1.3.3 Etude de l’existant

L’étude de l’existant permet une compréhension approfondie de domaine d’étude afin

d’élaborer un bilan analytique détectant les lacunes pour offrir une solution plus efficace.
Pour bien comprendre notre contexte, nous avons procéder d’analyser des systèmes de
télé-déclaration qui existent dans l’Afrique. Nous présentons ci-dessous les cas de la Tunisie,
d’Algérie et du Maroc. Mais avant tous, il est indispensable de comprendre qu’est ce qu’une
déclaration des impôts en mode traditionnel et quels sont ces atouts.

8
Déclaration des impôts

"L’impôt constitue un des prélèvements obligatoires effectué par voie d’autorité par la
puissance publique (l’État et les collectivités territoriales) sur les ressources des personnes
vivant sur son territoire ou y possédant des intérêts. Sans contrepartie directe pour le contri-
buable, ce prélèvement est destiné à être affecté par l’intermédiaire des budgets publics aux
services d’utilité générale" [5]. Dans les États démocratiques, le pouvoir de fixer, de lever
et d’affecter l’impôt est de la compétence exclusive du pouvoir législatif. Trois paramètres
essentiels permettent de caractériser un impôt : l’assiette, le taux et les modalités de recou-
vrement.
Historiquement, l’impôt est un élément important qui n’a cessé de conditionner l’existence,
la gestion et la puissance des États : constituant généralement une part importante, pour ne
pas dire la plupart du temps essentielle, des recettes publiques avec les cotisations sociales,
les impôts alimentent le budget de l’État ou d’une subdivision nationale ou fédérale (comme
une province, une subdivision territoriale, un territoire, un département, un district, etc.), et
dans une moindre mesure des organismes à compétence spécialisée.
L’impôt est généralement pécuniaire, exigé des personnes (physiques ou morales, pu-
bliques ou privées, locales ou internationales), en fonction de leurs capacités contributives,
par la puissance publique, d’après une procédure et des règles fixes, à titre définitif, et sans
contrepartie immédiate, en vue de la couverture des charges publiques, et de la poursuite de
politique économique et sociale.

Tunisie : e-Jebaya

Le système de la télé-déclaration et du télé-paiement est un service gratuit destiné aux

contribuables et aux professionnels habilités par la loi ( experts comptables, comptables,
conseillers fiscaux, centres de gestion intégrés, bureaux d’encadrement et d’assistance fiscales,
...) [6]. Ce service permet de déclarer et payer les taxes et impôts exigibles via Internet. Le
système de la télé-liquidation avec paiement à la recette des finances permet de liquider les
impôts et taxes exigibles via Internet sans l’utilisation d’un certificat électronique et les payer
à partir du jour suivant à n’importe quelle recette des finances.
La figure ci dessous présente la page d’accueil du système e-Jebaya, après l’authentifica-
tion.

9
 Figure 1.4 – Système télé-déclaration des impôts en Tunisie [6]

Algérie : Jibaya’Tic

En Algérie le service du télé-déclaration [7] propose au contribuable de liquider ses obli-

gations fiscales par internet et d’initier un processus adapté de paiement par virement via le
dispositif bancaire d’acquittement de masse. Pour être prise en compte, la télé-déclaration
doit obligatoirement être accompagnée par l’émission de l’ordre de virement associé, tel que
prescrit dans ce service. Ce service présente les avantages suivants :
• Il est gratuit et simple d’accès,
• Il est sécurisé avec une accessibilité et disponibilité optimales,
• Il offre une traçabilité des échanges avec l’administration fiscale grâce à un suivi des
déclarations envoyées,
• Il offre un tableau de bord sur les opérations effectuées.
Ce service est proposé aux contribuables relevant des nouvelles structures (DGE, CDI,
CPI). Ce service dématérialise la procédure manuelle de déclaration fiscale. Pour y adhérer
, une procédure simple de souscription est élaborée. L’adhésion à ce service ouvre droit à un
espace privé et sécurisé sur le portail, où ils sont déclinées les fonctionnalités suivantes :
• L’accès à ses données d’identification (avec possibilité de mise à jour du code d’accès),
• La saisie assistée des déclarations avec calcul automatique,
• La possibilité d’imprimer un avis de payement avec le détail des impôts et montants
déclarés,
• L’accès à un dispositif de suivi continu des déclarations émises,

10
 • Une documentation complète sur le système fiscal algérien sur le site web.

Figure 1.5 – Exemple des formulaires de télé-déclaration en Algérie [7]

Maroc : SIMPL

Le service SIMPL [8], est le service de télé-déclaration marocain. Il permet aux entreprises
marocaines de s’acquitter de leurs obligations fiscales en ligne. La télé-déclaration est obliga-
toire pour toutes les entreprises. Les entreprises qui ne passent pas au mode de déclarations
en ligne auront à payer une pénalité de 15% sur le montant à régler. Les services SIMPL
actuellement disponibles se présentent comme suit :
• SIMPL-Adhésion : pour l’adhésion en ligne aux services SIMPL,

Figure 1.6 – Formulaire d’adhésion aux service SIMPL [8]

11
 • SIMPL- TVA : pour la déclaration et le paiement en ligne de la taxe sur la valeur
ajoutée,
• SIMPL-IS : pour la télé-déclaration et le télé-paiement de l’impôt sur les sociétés,
• SIMPL-IR : pour la télé-déclaration du Revenu global annuel.

Figure 1.7 – Exemple des formulaires de télé-déclaration du système SIMPL [8]

La figure ci-dessous présente un formulaire exemplaire pris du système de télé-déclaration
des impôts en Algérie.

Cette plateforme de télé-déclaration a plusieurs avantages en terme de gain de temps,

opter pour la déclaration en ligne permet d’éviter les tâches répétitives, les recopies, la docu-
mentation lourde ainsi que les nombreux déplacements. Aussi ce service assure la réduction
des erreurs puisqu’il est possible de modifier et de corriger les données à tout moment avant
la validation définitive. Il offre un meilleur suivi tant qu’il y a plus de visibilité dans le suivi
des étapes de la prise en main de la déclaration en ligne. Le point fort qui spécialise ce service
est que l’alimentation des données est automatique à partir d’un ERP.

1.3.4 Problématique

Généralement les systèmes de télé-déclaration des impôts ressemblent. Nous trouvons

des différences au niveau de la manière de calcul des impôts elles mêmes ou bien dans des
détails qui n’affectent pas le démarche et la logique générale d’une déclaration des impôts.

12
Nous citons comme exemple le pourcentage de revenu à payer comme étant impôts. Même
si dans le même pays et le même système, ce taux change régulièrement avec le changement
du loi des finances du pays concernés. De sa part, ArabSoft comme étant spécialiste dans
l’élaboration des systèmes de gestions généralement, elle reçoit une très forte demande sur
les systèmes de télé-déclaration. Comme le marché Africain, est le plus demandeur de service
chez ArabSoft, donc la direction des projets sous laquelle nous effectuions notre stage a décidé
de produire un système qui répond à tous les contraintes d’un système de télé-déclaration.
Ce dernier doit être générique avec la possibilité de paramétrage en cas de besoin de modifier
l’un des paramètres. Par conséquent notre problématique est de trouver une solution à cette
question : comment peut on concevoir et développer un système de télé-déclaration des impôts
qui s’adapte facilement aux changement régulier, ou bien d’un pays à un autre ?

1.3.5 Solution proposée

La mission de chercher une solution pour la problématique en dessus, nous a été confier.
Nous avons passer au début de notre stage une période consacré à la recherche et l’étude,
afin de fournir une solution efficiente. Nous avons donner le nom "OnImpôts" pour notre
solution, extrait du mot anglaise "Online" qui signifie en ligne, et le mot impôts concerne
l’objectif principale du notre solution. La figure 1.8 représente le logo choisi pour notre so-
lution. C’est un système qui profite des nouvelles technologies et tendances dans le monde
de génie logiciel. OnImpôts devra être équipée d’une interface graphique intuitive et simple
de tel façon à ne nécessiter un apprentissage particulier de la part de ses utilisateurs. Notre
solution doit respecter la procédure réelle d’une déclaration d’impôts. Cette procédure com-
mence lorsque un citoyen(personne physique ou morale), se déplace chez le service local de
l’autorité responsable le plus proche, pour déposer une demande d’adhésion. Cette dernière
doit fournir un grand nombre des informations concernant le contribuable, ainsi que les pièces
justificatives. Après le dépôt, la demande va être transférer au spécialistes pour l’étude et
la validation. Une fois la demande d’adhésion est validé, un numéro d’identification fiscale
(NIF) sera attribué à ce contribuable. Il fera partie du système d’information de l’autorité,
à ce stade. Par suite, il doit se déplacer au même service, pour faire ses déclarations d’im-
pôts. Selon le type d’activité, le revenu et plusieurs autres critères, cet acte de déclaration
se répète périodiquement, il peut se faire même chaque mois. Notre objectif pour ce projet,
est d’informatiser le système d’information existant. Par suite, tous les processus vont être

13
migrer du classique et traditionnel, aux numériques. Notre système, OnImpôts doit offrir
principalement les processus suivants qui se divisent en deux grandes parties :
• Coté contribuable : les interfaces de déclaration des impôts qui s’affichent chez le
contribuable.
— Demander l’adhésion au système : cet étape représente tout un processus com-
plexe, ce n’est pas une simple inscription. Le contribuable rempli un ensemble des
formulaires et joint les pièces justificatives et les enregistrent sur le système. Et il
attend que son demande soit étudier et valider par l’administration.
— S’authentifier : une fois la demande d’adhésion est validé, le contribuable peut se
présenter au système pour faire des déclarations d’impôts.
— Déclarer ses impôts : tous comme la procédure classique, la déclaration d’impôts
en ligne est un ensemble des formulaires à remplir dûment, totalement dépendante
du type et secteur d’activité et surtout aux revenus qu’il gagne le contribuable.
— Valider sa déclaration : le contribuable peut remplir les formulaires des déclara-
tions, et revenir plus tard pour les modifier ou les valider tant que les délais ne
sont pas encore dépasser. Une fois valider la déclaration en question ne peut pas
être rectifier. En ce moment, la direction peut consulter la déclaration.
— Se documenter : le système doit offrir une large gamme de documentation, conte-
nant un guide d’utilisation, les textes législatives, etc.
• Coté Administration (Autorité) : les interfaces d’administration qui s’affichent chez
l’employé responsable confié.
— Valider une demande d’adhésion : une demande d’adhésion déposer par un contri-
buable, doit être valider par la direction, en vérifiant les informations données, et
les documents justificatives. La direction attribue un NIF à chaque contribuable,
c’est le plus important identifiant pour faire des opérations de déclaration d’impôts.
— Gérer un compte d’un contribuable : l’administrateur système peut effectuer les
opérations de gestion sur le compte du contribuable, par exemple il peut désactiver
un compte d’une personne morale si elle n’existe plus cause à une faillite.
— Consulter une déclaration validé.

14
 Figure 1.8 – Logo OnImpôts

1.4 Méthodologies de travail

Avant la réalisation d’un projet informatique, il est nécessaire de choisir une méthodologie
de travail et un procès de suivi afin d’aboutir à la fin à un logiciel fiable. Cette méthodologie
présente un procédé qui a pour objectif de permettre de formaliser les étapes préliminaires
du développement d’un système afin de rendre ce développement plus fidèle aux besoins du
client. Afin de fixer une méthode particulière, nous avons effectué une étude comparative
entre les différentes méthodes qui existent. Nous avons constatés que chaque méthodologie
ou bien approche a tant des avantages que des inconvénients. Du coup, nous avons décidé de
tiré les meilleurs notions et les bonnes pratiques des méthodologies qui s’alignent bien avec
nos objectifs et nos besoins. La première approche qui nous avons mis en considération, est
l’architecture dirigée par les modèles, MDA. Puisque nous avons un système d’information
existant et nous voulons le digitaliser, et c’est exactement que fait le MDA. Nous profitant
de l’approche DevOps qui maximise la collaboration entre le développement et l’exploitation.
DevOps minimise la durée de cycle de vie du projet en automatisant le maximum des tâches.
Finalement, nous avons choisi le processus unifié, spécifiquement le RUP, qui nous aide à dé-
finir les étapes de gestion du projet. Nous détaillons dans la partie suivante ces méthodologies
en précisant ce que nous intéressent exactement.

1.4.1 Architecture dirigée par les modèles

Après la technologie procédurale, la technologie objet et la technologie des composants,

l’approche MDA (Model Driven Architecture) est un processus de l’ingénierie dirigée par les
modèles [9]. Proposée par l’OMG (Object Management Group) en 2000, l’approche MDA est
basée sur la séparation des préoccupations. Elle permet prendre en compte, séparément, as-

15
pect métier et aspect technique d’une application, grâce à la modélisation. L’approche MDA
[10] distingue deux aspects principaux dans le processus de développement d’une application,
l’aspect métier qui représente les fonctions de l’application, et l’aspect technique qui repré-
sente la technologie de mise en œuvre de l’application. Chaque aspect est exprimé par un
ensemble de modèles, qui véhiculent l’information nécessaire à la génération du code source
de l’application. On passe d’une vue contemplative des modèles à une vue productive. MDA
définit trois niveaux de modèles représentant les niveaux d’abstraction de l’application, le
CIM, le PIM et le PSM :
• Modèle CIM- Computational Independant Model :
Les modèles d’exigence CIM décrivent les besoins fonctionnels de l’application, aussi
bien les services qu’elle offre et les entités avec lesquelles elle interagit. Leur rôle est
de décrire l’application indépendamment des détails liés à son implémentation. Les
CIM peuvent servir de référence pour s’assurer que l’application finie correspond aux
demandes des clients.
• Modèle PIM- Platform Independant Model :
Les modèles PIM sont les modèles d’analyse et de conception de l’application. La phase
de conception à cette étape du processus suppose l’application de Design pattern, le
découpage de l’application en modules et sous-modules, etc. Le rôle des PIM est de
donner une vision structurelle et dynamique de l’application, toujours indépendam-
ment de la conception technique de l’application.
• Modèle PM- Platform Model :
Rarement utilisé, un PM décrit la structure, et les fonctions techniques relatives à
une plateforme d’exécution (systèmes de fichiers, de mémoire, de BDD. . .) et précise
comment les utiliser. Le PM est associé au PIM pour obtenir le PSM.
• Modèle PSM- Platform Specific Model :
Le PSM est le modèle qui se rapproche le plus du code final de l’application. Un
PSM est un modèle de code qui décrit l’implémentation d’une application sur une
plateforme particulière, il est donc lié à une plateforme d’exécution.
• Code source :
Représente le résultat final du processus MDA, le code source est obtenu par génération
automatique (partielle ou totale) du code de l’application à partir du PSM. Le code
source obtenu peut toujours être enrichi ou modifié manuellement.
L’OMG a défini l’approche MDA pour répondre aux problèmes liés à l’évolution continue

16
des technologies. MDA est à l’origine de l’ingénierie dirigée par les modèles. Tout ce qui
constitue l’approche MDA, la modélisation, les transformations, les technologies de mises en
œuvre. . . a été pensé afin de permettre à MDA de remplir les objectifs suivants :
• La pérennité des savoir-faire :
La technologie évolue plus vite que les métiers de l’entreprise. Il semble alors plus
intéressant de capitaliser les savoir-faire de l’entreprise indépendamment des préoccu-
pations techniques.
• Les gains de productivité :
Les modèles sont au cœur du processus MDA, ils facilitent la communication entre
experts du domaine et développeurs. mais pas seulement. Dans MDA les modèles
deviennent un outil de production grâce à l’automatisation des transformations de
modèles.
• La prise en compte des plateformes d’exécution :
À partir du PIM, MDA permet d’intégrer les spécifications techniques d’une plate-
forme d’exécution dans les transformations PIM vers PSM, et d’obtenir ainsi un PSM
spécifique à la plateforme d’exécution, à partir duquel le code source de l’application
est généré.

1.4.2 DevOps

DevOps est une approche basée sur les principes Lean et Agile et qui regroupe l’ensemble
des parties prenantes (développement, assurance qualité, exploitation) collaborant ensemble
pour délivrer des logiciels en continu [11]. Ceci permet donc aux entreprises de saisir plus
rapidement les opportunités du marché et d’accélérer la prise en compte des retours clients.
Également, elle permet de rapprocher les perspectives antagonistes en aidant les équipes à
définir ensemble les objectifs métier et à les modifier en continu en fonction des retours de
manière à améliorer à la fois l’agilité et les résultats d’entreprise. DevOps intervient donc sur
l’ensemble du cycle de vie des applications. DevOps améliore la manière dont les entreprises
apportent de la valeur à leurs clients, fournisseurs et partenaires. Elle offre les avantages sur
les 3 domaines ci-dessous :
• Amélioration de l’expérience client : permet de fidéliser les clients et d’accroître les
parts de marché. Pour apporter cette expérience, une entreprise doit obtenir et ré-
pondre en continu aux retours clients.

17
 • Accroissement de la capacité à innover : DevOps applique les pratiques Lean afin de
réduire le gaspillage et la reprise de travail tout en exécutant les activités à forte valeur
ajoutée.
• Accélération du retour sur investissement : implique de développer une culture, des
pratiques et une automatisation afin de délivrer les logiciels rapidement, efficacement
et de manière fiable jusqu’à la mise en production.
Tandis que l’approche MDA, et la méthode DevOps, nous aide à réaliser les objectifs de
notre projets, ils ne définit pas un cycle de vie claire pour une solution logicielle. Ce que
nous pousse à choisir une méthode qui définit les étapes de création d’un logiciel, afin de bien
planifier pour notre projet. Notre choix consiste en la méthode RUP.

1.4.3 Processus Unifié : RUP

La méthode du Processus Unifié (UP pour Unified Process) est un processus de dévelop-
pement itératif et incrémentale [12], ce qui signifie que le projet est découpé en phases très
courtes à l’issue de chacune desquelles une nouvelle version incrémentée est livrée.
Il s’agit d’une démarche s’appuyant sur la modélisation UML pour la description de l’ar-
chitecture du logiciel (fonctionnelle, logicielle et physique) et la mise au point de cas d’utili-
sation permettant de décrire les besoins et exigences des utilisateurs. RUP (Rational Unified
Process) est une méthode de développement par itérations promue par la société Rational
Software, rachetée par IBM [13]. RUP propose une méthode spécifiant notamment la compo-
sition des équipes et le calendrier ainsi qu’un certain nombre de modèles de documents. RUP
est l’une des plus célèbres implémentations de la démarche UP, livrée clé en main, permet-
tant de donner un cadre de développement logiciel, répondant aux exigences fondamentales
préconisées par les créateurs d’UML. RUP est une version commerciale d’UP. Le processus
unifié regroupe les activités à mener pour transformer les besoins d’un utilisateur en système
logiciel. Ces principales caractéristiques sont :
• Il est à base de composants,
• Il utilise le langage UML (ensemble d’outils et de diagrammes),
• Il est piloté par les cas d’utilisation,
• Il est centré sur l’architecture,
• Il est itératif et incrémentale.
Le cycle de vie d’un projet est propagé sur quatre phases, regroupé dans une itération. Chaque

18
itération résulte une nouvelle version du produit. La figure 1.9 présente le cycle de vie d’un
projet RUP [12]. Les quatre phases du RUP sont consécutives et se présentent comme suit :
• La phase d’inception :
— Établir la portée du projet et les conditions aux limites
— Déterminer les cas d’utilisation et les scénarios principaux
— Proposer une architecture
— Estimer le coût global et le calendrier
— Identifier les risques potentiels et leurs sources
— Démontrer que le système proposé est en mesure de résoudre
— les problèmes ou de prendre en charge les objectifs fixés
— Vision : Glossaire, Détermination des parties prenantes et des utilisateurs, Déter-
mination de leurs besoins, Besoins fonctionnels et non fonctionnels, Contraintes de
conception
• La phase d’élaboration :
— Définir et valider l’architecture de base
— Formuler les cas d’utilisation pour couvrir environ 80% des besoins fonctionnels
— Définir les niveaux de qualité à atteindre,
— Etablir un plan détaillé pour la phase de construction
— Démontrer que l’architecture de base prend en charge «la vision» à un coût rai-
sonnable dans un délai raisonnable
— Architecture : Document d’architecture Logicielle, Différentes vues selon la partie
prenante, Comportement et conception des composants du système
• La phase de construction :
— Produire un logiciel utilisable conforme aux besoins
— Confronter ce logiciel aux critères d’acceptation
— Extension de l’identification, de la description et de la réalisation des cas d’utili-
sation
— Finalisation de l’analyse, de la conception, de l’implémentation et des tests
• La phase de transition :
— Préparation des activités
— Recommandations au client sur la mise à jour de l’environnement logiciel
— Élaboration des manuels et de la documentation concernant la version du produit
— Adaptation du logiciel

19
 — Correction des anomalies liées au bêta test
— Dernières corrections

Figure 1.9 – Le cycle de vie d’un produit gérer par RUP [12]

1.5 Méthodologie de modélisation

1.5.1 Le langage UML

UML(Unified Modelling Language) est le langage de modélisation imposé par MDA et

le processus unifié en même temps. D’ailleurs, c’est une notation qui permet de modéliser
un problème de façon standard. Ce langage qui est né de la fusion de plusieurs méthodes
existantes auparavant et devenu une référence en terme de modélisation objet. UML est :
• un langage formel et normalisé.
• précise, encourage l’utilisation d’outils.
• un support de communication performant.
• polyvalent, souple et universel.

20
1.5.2 Les diagrammes UML : les 4+1 vues

Le modèle « 4+1 » vues [14], dit de Kruchten, d’un système informatique permet d’or-
ganiser la description du système en plusieurs vues complémentaires, chacune présentant le
système selon un point de vue différent. L’utilisation de vues permet de traiter séparément
les intérêts des divers groupes d’intervenants (architectes, utilisateurs, développeurs, chefs de
projets, etc.) et ainsi de mieux séparer les préoccupations fonctionnelles (le domaine d’appli-
cation ou métier ciblé par le système, et les préoccupations extrafonctionnelles (les propriétés
techniques telles que la sûreté de fonctionnement). La figure 1.10 [14] schématise le modèle
« 4+1 » vues.

Figure 1.10 – le modèle 4+1 vue d’UML [14]

• La vue « logique » décrit les aspects statiques et dynamiques d’un système en termes
de classes, d’objets, de connexions et de communications. Elle se concentre sur l’abs-
traction et l’encapsulation.
• La vue « processus » capte les aspects de concurrence et de synchronisation, et les

21
 décompose en flux d’exécution (processus, fil d’exécution, etc.). Elle se rapporte aux
objets actifs et aux interactions.
• La vue « développement » représente l’organisation statique des modules (exécutable,
codes source, paquetages, etc.) dans l’environnement de développement.
• La vue « physique » décrit les différentes ressources matérielles et l’implantation lo-
gicielle tenant compte de ces ressources. Donc, elle se rapporte aux nœuds physiques
d’exécution et au placement des objets sur les nœuds.
• La dernière vue, appelée « cas d’utilisation », se concentre sur la cohérence en présen-
tant des scénarios d’utilisation qui mettent en œuvre les éléments des quatre premières
vues. Les scénarios sont une abstraction des exigences fonctionnelles de l’application.
Cette dernière vue valide en quelque sorte les autres vues et assure la cohérence glo-
bale. C’est aussi cette dernière vue qui est construite en premier, juste après l’établis-
sement du cahier des charges, pour fixer les contours du système à réaliser avec ses
fonctionnalités appelées, dans la terminologie UML, des cas d’utilisation.
Il n’est pas obligatoire d’utiliser tout ces diagrammes pour concevoir un système, selon
les besoins de chaque projet, nous faisons le choix des diagrammes. Pour notre projet, nous
inspirons des modèles MDA, pour choisir. Le CIM peut être présenté par un diagramme de
cas d’utilisation. Il offre la faculté de définir l’ensemble des acteurs et des cas d’utilisation
sans en détailler le fonctionnement. Le PIM, peut être représenter par le diagramme de classe.
Aussi nous présentons les diagrammes des séquences pour mieux spécifier le comportement
de notre système.

1.6 Conclusion
Dans ce chapitre nous avons étudier généralement notre projet. Nous avons proposer une
solution pour la problématique tiré depuis l’étude de l’existant et le contexte générale du
projet. Nous avons choisi MDA et DevOps pour nous aider à bien réaliser nos objectifs. Pour
la gestion du projet, nous allons suivre la méthode RUP. Dans les chapitres qui suivent, nous
allons suivre le démarche de cette méthode. Commençons par la phase d’inception dans le
chapitre suivant.

22
Chapitre 2

Inception

2.1 Analyse et spécification des besoins

Les besoins fonctionnels et non fonctionnels feront l’objet de cette partie. Elle nous per-
mettra de comprendre les espérances de l’organisme d’accueil. La phase d’analyse et spéci-
fication des besoins est la première phase formelle obligatoire dans le développement d’une
application informatique puisque la capacité de persuasion d’un produit ne peut se réaliser
parfaitement sans une spécification préalable élaborée des besoins et des exigences.

2.1.1 Besoins fonctionnels

Il s’agit de mettre en exergue les fonctionnalités de notre application. Ce sont les besoins
spécifiant un comportement d’entrée-sortie du système. Nous n’oublions pas de préciser que
cette liste des besoins permet une certaine flexibilité. Globalement notre application devra
être équipée des fonctionnalités suivantes :
• Côté Administration :
— Authentification : l’administrateur doit s’authentifier pour accéder à ses fonction-
nalités, les données de connexion, vont être stockés directement sur l’application.
— Valider les inscriptions : l’administrateur doit valider les demandes d’adhésion au
système, pour que le processus d’inscription lancé par le contribuable s’achève.
— Gérer le compte d’un contribuable : l’administrateur peut intervenir sur le compte
d’un contribuable, pour faire des mise à jours ou bien pour le supprimer en cas de
besoin, par exemple si une société n’existe plus à cause d’une faillite.
— Consulter les déclarations : l’administrateur peut consulter les déclarations d’im-

23
 pôts, afin de les auditer. S’il remarque une anomalie, il peut lancer un processus
d’audit. Ce processus n’est pas gérer par notre système pour le moment.
— Gérer la plateforme : Ce module sert initialement à contrôler la plateforme et d’une
autre part, il offre la possibilité du paramétrage de la plateforme en cas de besoin
d’une modification de quelques paramètres.
• Côté Contribuables :
— Authentification : le contribuable doit s’authentifier pour accéder à son espace, les
données de connexion sont stockés sur la base des données.
— Gérer son profil : le contribuable peut modifier son profil à tout moment.
— Déclarer ses impôts : le contribuable peut déclarer ses impôts, en lui offrant un
système d’aide à la calcul. Il peut laisser ses déclarations en état non validé pour
revenir ultérieurement les valider. Pendant la période entre la déclaration et sa
validation, il peut la rectifier. Seul le contribuable lui même peut consulter la
déclaration en ce moment.
— Valider les déclarations : une fois validées, les déclarations ne peuvent jamais être
modifier.
— Se déconnecter.
• Côté invité : un utilisateur invité peut s’inscrire sur la plateforme. L’inscription à notre
plateforme nécessite tout un processus : le contribuable procède à remplir un formulaire
d’inscription bien détaillé contenant toute information qui semblent indispensable au
cours du processus de télé-déclaration. Une fois soumis par le contribuable, la demande
d’inscription doit être valider par l’administrateur.
• Tâches partagés : Les invités, comme les contribuables peuvent accéder à la documen-
tations.

2.1.2 Besoins non fonctionnels

Les besoins non fonctionnels présentent les exigences internes pour le système et cachées
vis à vis des utilisateurs. Les impératifs les plus immédiats de notre application pris en
considération sont :
• Sécurité : La solution doit être suffisamment sécurisée : identification, authentifica-
tion, gestion des utilisateurs, traçabilité . . .etc. Elle doit assurer l’intégrité, la confi-
dentialité et la disponibilité des documents.

24
 • Architecture WEB : La solution doit être basée, sur une architecture WEB permet-
tant son exploitation en modes Intranet, Extranet et éventuellement Internet. Décen-
tralisation : Permettre une gestion décentralisée (en cas de besoin) de la numérisation
et du stockage des archives tout en assurant une réplication des données vers une base
centrale.
• Faible couplage : Le couplage mesure la dépendance entre des classes ou des modules.
Le faible couplage favorise : la faible dépendance entre les classes, la réduction de
l’impact des changements dans une classe, la réutilisation des classes ou modules.
• Approche de programmation générique : La programmation générique repose sur
le principe de paramétrage de classes. Une classe définie dans un langage générique
peut admettre un ou plusieurs paramètres génériques formels, caractérisant son degré
d’ouverture. Les classes génériques permettent de découpler les préoccupations liées
à la définition de structures de données, par exemple, de la spécification du ou des
types de données concrets que détiennent ces structures. Il s’agit de la séparation de
préoccupations de données. Nous pouvons mettre en œuvre cet exigence en suivant
l’approche MDA.
• Qualité logiciel : notre application doit être conforme au norme ISO 25010 de la série
de normes ISO 250xx, également appelée SQuaRE (pour software quality requirements
and evaluation en anglais, c’est-à-dire exigences et évaluation de la qualité du logiciel).
• La rapidité de livraison : le temps de livraison pour notre projet est trop critique, le
cycle de vie totale ne doit pas dépasser quatre mois. Donc nous optons à automatiser
le maximum des tâches pour arriver dans le terme. La méthode DevOps pousse à ce
faire, ce que explique notre choix.

2.1.3 Identification des acteurs

Nous précédons par une détermination des acteurs et des cas d’utilisation : Un acteur
est toute entité qui interagit avec notre système dans le but de réaliser une plus-value et qui
a toujours le même comportement. Un cas d’utilisation est la description d’un ensemble de
séquences d’opérations qu’un système effectue pour répondre au besoin d’un acteur. Notre
application interagit avec les acteurs suivants :
• Administrateur : c’est l’employé qui est confié pour représenter l’autorité.
• Contribuable : c’est l’utilisateur connecté, qui vient de faire une déclaration d’im-

25
 pôts.
• Visiteur : c’est l’utilisateur non pas encore connecté.
Ces acteurs sont gérer comme étant des profils, donc il est impossible d’avoir deux profils en
même temps en s’opposant aux système. Par exemple, l’administrateur lorsqu’il veut déclarer
ses impôts, quant à lui, il faut se déconnecter du système. Par suite, il s’authentifie comme
étant un contribuable.

2.1.4 Diagramme de cas d’utilisation globale

Un diagramme de cas d’utilisation capture le comportement d’un système, d’un sous-

système, d’une classe ou d’un composant tel qu’un utilisateur extérieur le voit. Il découpe les
fonctionnalités du système en unités cohérentes, les cas d’utilisations, ayant un sens pour les
acteurs. Les cas d’utilisation permettent d’exprimer les besoin des utilisateurs d’un système
énumérés plus haut, ils sont donc une vision orientée utilisateur de ce besoin au contraire d’une
vision informatique. Tout ceci démontre que nous ne devons pas négliger cette première étape
pour produire un logiciel conforme aux attentes des utilisateurs. Suivant l’approche MDA, le
diagramme des cas d’utilisation remplace le CIM.
Les figure ci-dessous illustrent le diagramme de cas d’utilisations globale, il nous permet
d’obtenir une vision générale du comportement fonctionnel de l’application. La figure 2.1
représente le diagramme des cas d’utilisation globale.

26
 Figure 2.1 – Diagramme de cas d’utilisations globale

2.2 Définition des architectures

2.2.1 Application web

Nous avons choisi que notre solution soit une application web, puisque c’est le type de sys-
tème le plus facile à utiliser par les utilisateurs finaux. Elle possède des interfaces graphiques
intuitive, facile à comprendre et à manipuler. Elle ne nécessite qu’un ordinateur équipé par un
navigateur et un accès à internet. Elle ne demande aucune installation, ni configuration. De
plus, le développement des application web ne coûte pas trop cher. Et enfin, un développeur
des applications web, a un très large choix entre les langages et les frameworks.

2.2.2 Architecture applicative

L’architecture logicielle, tout comme l’architecture traditionnelle, peut se catégoriser en

styles . Un système informatique peut utiliser plusieurs styles selon le niveau de granula-
rité ou l’aspect du système décrit. Notre application opte à l’utilisation de l’architecture en
couches. Dans cette section, nous présentons l’architecture applicative de notre application.
Notre application suit le modèle architecturale MVC. C’est le fameux patron de conception
modèle-vue-contrôleur. Le modèle MVC [15] découpe littéralement l’application en couches

27
distinctes et de ce fait impacte très forcement l’organisation du code. MVC signifie Modèle
– Vue – Contrôleur, en gros quand on développe avec le MVC on segmente son code en trois
parties ou couches, chaque couche ayant une fonction bien précise. La figure 2.2 résume le
fonctionnement d’un modèle MVC.

Figure 2.2 – Modèle MVC [15]

La couche Vue

C’est la partie qui s’occupera de la présentation des données à l’utilisateur, elle retourne
une vue des données venant du modèle, en d’autres termes c’est elle qui est responsable
de produire les interfaces de présentation de l’application à partir des informations qu’elle
dispose.

La couche Contrôleur

C’est la couche chargée de router les informations, elle va décider qui va récupérer l’infor-
mation et la traiter. Elle gère les requêtes des utilisateurs et retourne une réponse avec l’aide

28
de la couche Modèle et Vue.

La couche Modèle

C’est la partie de code qui exécute la logique métier de l’application. Ceci signifie qu’elle
est responsable de récupérer les données, de les convertir selon les concepts de la logique de
l’application tels que le traitement, la validation, l’association et tout autre tâche concernant
la manipulation des données. Elle est également responsable de l’interaction avec la base de
données, elle sait en quelque sorte comment se connecter à une base de données et d’exécuter
les requêtes (CREATE, READ, UPDATE, DELETE) sur une base de données.

2.2.3 Architecture technique

La figure 2.3 présente la pile en couche qui met en œuvre l’architecture technique de
notre application. c’est une vision globale, sur les technologies les plus importantes utilisés
par notre application.

Figure 2.3 – Architecture technique de l’application

2.3 Choix technologiques

Durant le cycle de vie de notre application, nous avons utilisés plein des outils et tech-
nologies qui ont assurer le bon déroulement de ce cycle. Nous présentons dans cette section
une liste non exhaustif de ces outils et technologies, en suivant l’ordre chronologiques de
l’utilisation. La figure 2.4 présente en ensemble les différents logo des outils et technologies
listés.

29
 Figure 2.4 – Différents logo des outils et technologies utilisés

2.3.1 Java 8 SDK

Kit de développement logiciel Java Platform, Enterprise Edition 8 (Java EE 8) [16]. Java
est un langage de programmation et une plate-forme informatique qui ont été créés par
Sun Microsystems en 1995. Beaucoup d’applications et de sites Web ne fonctionnent pas
si Java n’est pas installé et leur nombre ne cesse de croître chaque jour. Java est rapide,
sécurisé et fiable. Des ordinateurs portables aux centres de données, des consoles de jeux
aux superordinateurs scientifiques, des téléphones portables à Internet, la technologie Java
est présente sur tous les fronts. Java donne accès à l’environnement JRE (Java Runtime
Environment). Cet environnement se compose de la Java Virtual Machine (JVM), des classes
standard de la plate-forme Java et des bibliothèques Java de prise en charge. L’environnement
JRE correspond à la partie exécution du logiciel Java et permet d’exécuter ce dernier dans
votre navigateur Web.

2.3.2 Maven

Maven permet de faciliter et d’automatiser certaines tâches de la gestion d’un projet

Java [17]. Maven nous aident à appliquer le principe d’automatisation des tâches inspirer par
DevOps. Il permet notamment :

30
 • d’automatiser certaines tâches : compilation, tests unitaires et déploiement des appli-
cations qui composent le projet ;
• de gérer des dépendances vis à vis des bibliothèques nécessaires au projet ;
• de générer des documentations concernant le projet.

2.3.3 Eclipse

Massivement utilisé en entreprise, c’est un outil puissant, gratuit, libre et multi-plateforme

[18]. Les avantages d’un IDE dans le développement d’applications web Java EE sont mul-
tiples, et sans toutefois être exhaustif en voici une liste :
• intégration des outils nécessaires au développement et au déploiement d’une applica-
tion ;
• paramétrage aisé et centralisé des composants d’une application ;
• multiples moyens de visualisation de l’architecture d’une application ;
• génération automatique de portions de code ;
• assistance à la volée lors de l’écriture du code ;
• outils de débogage. . .

2.3.4 Mysql server

MySQL s’est fait connaître à la fin des années 1990 comme étant un système de gestion de
bases de données relationnelles de choix pour les petits projets web, profitant principalement
de sa gratuité et de sa rapidité [19]. MySQL est capable d’offrir de bonnes performances
même sur des serveurs peu puissants. De plus, sa stabilité est excellente et, sur une instance
correctement configurée, il est très rare de voir MySQL planter ou de perdre des données.
Enfin, sa gratuité permet d’envisager des déploiements avec des centaines ou des milliers
d’instances si nécessaire sans pour autant dépenser des fortunes en licences.

2.3.5 Mysql workbench

Le logiciel de gestion et d’administration de base de données, MySQL Workbench, a été

crée en 2004 [19]. Il permet, entre autres, de créer/modifier/supprimer des tables/comptes
utilisateurs. Il a une interface graphique intuitive qui permet de visualier en temps réel les
informations comme le pourcentage d’occupation en mémoire et les connexions courantes. Ce
logiciel nécessite une connexion à un serveur MySQL.

31
2.3.6 Tomcat

Pour faire fonctionner une application web Java EE, nous avons besoin de mettre en place
un serveur d’applications. Il en existe beaucoup sur le marché : nous avons choisi d’utiliser
Tomcat [20], car c’est un serveur léger, gratuit, libre, multi-plateforme et assez complet
pour ce que nous allons aborder. On le rencontre d’ailleurs très souvent dans des projets en
entreprise, en phase de développement comme en production.

2.3.7 SpringBoot

Spring Boot est un nouveau framework créé par l’équipe de chez Pivotal, conçu pour sim-
plifier le démarrage et le développement de nouvelles applications Spring [21]. Le framework
propose une approche dogmatique de la configuration, qui permet d’éviter aux développeurs
de redéfinir la même configuration à plusieurs endroits du code. Spring Boot facilite le déve-
loppement d’applications fondées sur Spring en offrant des outils permettant d’obtenir une
application packagée en jar , totalement autonome. Ce qui nous intéresse particulièrement,
puisque nous essayons de développer des Microservices. SpringBoot, nous aide à mettre en
œuvre le principe d’automatisation des configuration, de gestion des bibliothèques et dépen-
dances, et plein d’autres tâches.

2.3.8 Postman

L’application Postman [22] est un outil pratique pour tester une API REST dans API
Gateway. Les différentes fonctionnalités offertes par Postman, nous permet de tester nos
services indépendamment juste après leur développement (back end) sans avoir besoin de la
partie graphique du système (front end).

2.3.9 Visual code

Visual Studio Code est présenté lors de la conférence des développeurs Build d’avril 2015
comme un éditeur de code cross-platform, open source et gratuit, supportant une dizaine
de langages [23]. Visual code nous permet de gérer le code de la partie front end. Il permet
d’organiser la structure du projet et la traiter graphiquement. Après l’écriture du code, il
nous permet de le compiler, et de détecter les erreurs s’ils existent.

32
2.3.10 Node js/Npm

Initialement gestionnaire de packages de Node.js, npm est aujourd’hui le gestionnaire de

packages du monde JavaScript [24]. On y trouve aussi bien des modules pour le backend que
pour le frontend. Nécessaire pour le programmation du front end en Angular.

2.3.11 Angular Cli

Google nous propose un outil clé en main pour réaliser les tâches de développement les
plus courantes. Grâce à notre Angular Cli [25], il est possible de :
• Créer une application from scratch via un scaffolding ;
• Générer des squelettes des composants type Components. . . ;
• Builder un projet ;
• Lancer des tests de type « End-to-End » ou « unitaire » ;
• Proxyfier le back end ; Et beaucoup d’autres choses. . .

2.3.12 Git

Git est un logiciel de gestion de versions décentralisé [26]. C’est un logiciel libre créé par
Linus Torvalds, auteur du noyau Linux. Git ne repose pas sur un serveur centralisé, mais
il utilise un système de connexion pair à pair. Un logiciel de gestion de versions s’articule
autour d’un concept très simple : la sauvegarde de l’entièreté des modifications faites sur
tous les fichiers du projet et le maintien du code source tout au long du processus de déve-
loppement. En d’autres termes, il s’agit d’un type d’archivage moderne muni de nombreuses
fonctionnalités. Git nous permet de gérer les versions automatiquement, comme conseillé par
DevOps.

2.3.13 Docker

Docker est une technologie de conteneurisation qui permet la création et l’utilisation de

conteneurs Linux [27]. La technologie Docker utilise le noyau Linux et des fonctions de ce
noyau, telles que les groupes de contrôle cgroups et les espaces de noms, pour séparer les
processus afin qu’ils puissent s’exécuter de façon indépendante. Cette indépendance reflète
l’objectif des conteneurs : exécuter plusieurs processus et applications séparément les uns
des autres afin d’optimiser l’utilisation de votre infrastructure tout en bénéficiant du même

33
niveau de sécurité que celui des systèmes distincts. Pour s’assurer du bon fonctionnement du
notre système après qu’il sort du mode développement au mode exploitation, nous utilisons
Docker.

2.4 Planification
Comme nous avons choisi de gérer notre projet en suivant la méthode RUP. Nous dé-
coupons notre travail en quatre phase inception, élaboration, construction et transition. Ces
phases seront découper en itérations et incréments. la première itération consiste en la phase
d’inception, c’est la phase actuelle de notre projet. Nous avons défini nos objectifs et besoins.
Ainsi que le diagramme de cas d’utilisation, puisque RUP est piloté par les use cases. Puis
nous avons défini tous qui est architecture, parceque RUP est centré sur l’architecture. Nous
avons défini en fin, nos choix technologiques. Il nous reste que la planification des itérations
au sein des autres phases. La phase d’élaboration, est découpé en quatre itérations. Le ta-
bleau suivant justifie le découpage et le nombre des itérations. Il représente les différentes
itérations, ainsi que les cas d’utilisations, les acteurs impliqués et une description pour chaque
cas :

34
 Table 2.1 – Découpage des cas d’utilisation en itérations et modules

Itération Module Cas D’utilisation Acteur Description

1 Inscription S’authentifier Administrateur, L’internaute doit
Contribuable s’authentifier pour
effectuer des tâches
que seul un
utilisateur connecté
peut les faire.
1 Inscription Valider inscription Administrateur l’administrateur doit
valider l’inscription
des utilisateurs pour
qu’ils puissent se
connecter au système.
2 Gestion Gérer compte contri- Administrateur l’administrateur peut
Compte buable gérer(modifier, lire,
ou supprimer un
compte)
3 Déclaration Consulter déclaration Administrateur l’administrateur peut
consulter les
déclarations validées
1 Inscription S’inscrire Invité Un invité peut
s’inscrire au système
4 Documentation Se documenter Invité, Contribuable Un invité ou un
contribuable peuvent
se documenter à
partir du système
2 Gestion Gérer le profil Contribuable Un contribuable peut
Compte gérer son profil
3 Déclaration Déclarer impôts Contribuable Un contribuable peut
déclarer ses impôts
3 Déclaration Valider déclaration Contribuable Un contribuable peut
valider ses
déclarations
1 Inscription Se déconnecter Contribuable Contribuable peut se
déconnecter

Nous optons à découper l’ensemble des cas d’utilisations en modules. Chaque module,
contient les cas d’utilisations qui se complètent pour créer un processus. Par suite, nous
affectons chaque module à une itération de la phase d’élaboration pour notre cycle de dé-
veloppement en suivant la méthode processus unifié RUP. Nous avons choisi que le module
inscription soit traité le premier puisqu’il ne dépend pas des autres modules. Par contre les
autres modules dépend de lui. Le deuxième et le troisième module dépend tous les deux du
premier, mais ils ne dépend pas l’un de l’autre, donc nous pouvons les traiter dans n’importe

35
quel ordre. Le quatrième module ne dépend pas des autres modules, mais il n’est pas cri-
tique pour notre solution. La documentation dépend des textes législatives et des paramètres
spécifiques pour chaque pays, donc nous éliminons cette cas d’utilisation pour ce niveau. La
phase du construction sera découpé en 2 sous-phases, l’une pour la construction de la partie
backend et l’autre pour la construction de la partie frontend. Ces deux sous-phases seront
découpé sur quatre itérations chacune. Par analogie au principe de découpage des itérations
de la phase d’élaboration, nous découpons les itérations de la phase de construction. Donc
nous obtenons pour les quatre modules dans chaque sous-phase, huit itérations en total. La
phase de transition sera effectué dans une seule itération.

2.4.1 Diagramme de Gantt

La planification est parmi les phases d’avant projet les plus importantes. Elle consiste à
déterminer et à ordonnancer les tâches du projet et à estimer leurs charges respectives. Pour
planifier notre projet et suivre l’avancement, nous avons utilisé le diagramme de GANTT
[28]. Ce diagramme permet de planifier le projet et de rendre le suivi de son avancement plus
simple. La figure du diagramme de GANTT suivante représente la planification des phases
et itérations dans notre projet en fonction du temps :

Figure 2.5 – Diagramme de Gantt

36
 Figure 2.6 – Planification du projet

2.5 Conclusion
A travers ce premier chapitre, nous avons pu se placer dans le contexte général de notre
projet en introduisant le domaine de l’application ainsi que le cadre du travail. La détermi-
nation des besoins fonctionnels et non fonctionnels nous a permit de mieux clarifier notre
application, de bien mettre au point nos objectifs au cours de la phase suivante, qui est la
phase d’élaboration. Enfin, nous avons défini les méthodologies et approches à considérer
tout au long de notre projet, qui sera suivit par un diagramme de Gantt.

37
Chapitre 3

Élaboration

Dans ce chapitre nous traitons l’aspect conceptuel de notre application. Pour la conception
et la réalisation de cette dernière, nous nous appuyons sur le formalisme UML basé sur les
diagrammes et offrant une flexibilité marquante. Ces digrammes représentent parfaitement
les modèles exigés par MDA.

3.1 Itération 1 : Le module d’inscription

La première itération dans notre processus de développement de la plateforme de télé-
déclaration des impôts, traite le module d’inscription. Puisque c’est un passage obligatoire
pour l’utilisateur en face de notre système, pour pouvoir accéder les autres module. Ce module
est le point d’entrée pour notre système. Donc nous détaillons en ce que suit, le diagramme
de cas d’utilisation point le module Inscription, puis le diagramme de séquence. En fin, nous
présentons un prototype et les scénarios possible de ce module.

38
3.1.1 Diagramme de cas d’utilisation module inscription

Figure 3.1 – Diagramme de cas d’utilisation du module Inscription

Le module inscription englobe les cas d’utilisation qui assurent l’adhésion de l’utilisa-
teur au système, puis sa connexion et déconnexion. Cette phase est primordiale pour notre
système. Le tableau suivant décrit le cas d’utilisation "s’inscrire".

Table 3.1 – Description de cas d’utilisation "s’inscrire"

Cas d’utilisation S’inscrire

Acteur Contribuable
Pré-condition Cliquer sur le bouton "s’inscrire"
Post-condition Contribuable inscrit dans la base de données
Scénario-nominale Le contribuable saisit ses informations, et les
enregistre
Exception Annuler la procédure à cause des informa-
tions manquantes

Le tableau suivant décrit le cas d’utilisation "valider inscription".

39
 Table 3.2 – Description de cas d’utilisation "valider inscription"

Cas d’utilisation Valider inscription

Acteur Administrateur
Pré-condition un contribuable s’inscrit nouvellement
Post-condition L’inscription du contribuable est validée
Scénario-nominale L’administrateur vérifie les informations du
contribuable et valide son inscription
Exception Annuler la procédure à cause des informa-
tions manquantes ou erronées

3.1.2 Diagramme d’activités module inscription

Les diagrammes d’activités permettent de mettre l’accent sur les traitements. Ils sont
donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de
flots de données [14]. Ils permettent ainsi de représenter graphiquement le comportement
d’une méthode ou le déroulement d’un cas d’utilisation. Les diagrammes d’activités sont
particulièrement adaptés à la description des cas d’utilisation. Plus précisément, ils viennent
illustrer et consolider la description textuelle des cas d’utilisation. De plus, leur représentation
sous forme d’organigrammes les rend facilement intelligibles et beaucoup plus accessibles que
les diagrammes d’états-transitions. On parle généralement dans ce cas de modélisation de
workflow. On se concentre ici sur les activités telles que les voient les acteurs qui collaborent
avec le système dans le cadre d’un processus métier. La figure 3.2 présente le diagramme
d’activité pour le module d’inscription.

40
 Figure 3.2 – Diagramme d’activité pour le module d’inscription

3.1.3 Diagramme de séquences module inscription

Le diagramme de séquences est la représentation graphique des interactions entre les ac-
teurs et le système selon un ordre chronologique dans la formulation UML [14]. Ce diagramme
est utilisé pour représenter certains aspects dynamiques d’un système : dans le contexte d’une
opération, d’un système, d’un sous-système, d’un cas d’utilisation selon un point de vue tem-
porel. La figure 3.3 présente le diagramme de séquences du cas d’utilisation "s’inscrire".

Figure 3.3 – Diagramme de séquences pour l’interaction S’inscrire

41
 Pour le module inscription, lorsque l’internaute clique sur le bouton s’inscrire, il sera
dirigé vers le formulaire d’inscription, il doit remplir ce formulaire dûment et clique sur un
bouton pour soumettre sa demande d’inscription. Cette demande doit être vérifier et valider
par l’administrateur système, si les données pré-rempli sont valide, sinon, l’administrateur va
rejeter cette demande, les informations seront supprimer de la base. Cette interaction dépend
de l’interaction "Valider Inscription" effectuer par l’administrateur. La figure ?? présente le
diagramme de séquence pour le cas d’utilisation "Valider inscription".

Figure 3.4 – Diagramme de séquence du cas d’utilisation "Valider inscription"

Dans le même module, une fois inscrit, un contribuable demande son authentification et
le système lui renvoie le formulaire à remplir, Il saisie ses identifiants .Le système vérifie les
identifiants s’ils sont valide, le système affiche la page d’accueil sinon il envoie un message
d’erreur.

42
 Figure 3.5 – Diagramme de séquences pour l’interaction S’authentifier

3.2 Itération 2 : module gestion compte

Une fois inscrit, le contribuable possède un compte sur le système. Ce module permet la
gestion de ce compte par le contribuable lui même ou bien par l’administrateur. Le contri-
buable peut faire des mise à jours sur ses informations en cas de besoin. l’administrateur peut
intervenir sur le compte du contribuable pour le mettre sous l’état inactif, si par exemple
c’est une société qui a envisagé une faillite, ou bien si c’est une personne physique qui est
décédé.

3.2.1 Diagramme de cas d’utilisation module gestion compte

La figure 3.6 représente le diagramme de cas d’utilisation du module gestion compte, en

précisons les acteurs intervenant.

43
 Figure 3.6 – Diagramme de cas d’utilisation gestion du compte contribuable

Le tableau suivant 3.3 décrit le cas d’utilisation "gérer profil", de même pour le cas d’uti-
lisation "gérer compte contribuable" fait par l’administrateur. .

Table 3.3 – Description de cas d’utilisation "gérer profil"

Cas d’utilisation Gérer profil

Acteur Contribuable
Pré-condition un contribuable clique sur le bouton de mo-
dification
Post-condition le profil du contribuable est mis à jours
Scénario-nominale le contribuable modifie quelques informa-
tions sur son profil
Exception coupure de connexion

3.2.2 Diagramme de séquences module gestion du compte contri-

buable

Pour gérer un compte contribuable, l’utilisateur quelque soit un contribuable ou bien

un administrateur doit s’authentifier. Il peut cliquer sur le bouton "edit" , sur le formulaire
qui s’affiche il modifie les champs voulu et clique sur le bouton "submit" pour valider les
modifications. Une fois ces derniers sont validées, il sera redirigé vers la page d’accueil. Ce
processus est représenté par le diagramme de séquence suivant 3.7 :

44
 Figure 3.7 – Diagramme de séquences du processus gestion profil contribuable

3.3 Itération 3 : module déclaration des impôts

Ce module est le noyau de notre plateforme. Le contribuable authentifié clique sur le
bouton "déclarer des impôts", il sera renvoyé vers des formulaires spécifiques selon son profil.
Il rempli les champs du formulaire, il peut valider sa déclaration immédiatement ou bien il
peut revenir ultérieurement pour la valider, s’il n’a pas dépasser les délais. Ces derniers sont
fixés par la direction responsable.

3.3.1 Diagramme de cas d’utilisation module declaration des im-

pôts

La figure 3.8 représente le diagramme de cas d’utilisation du module déclaration des

impôts, en précisons les acteurs intervenant.

45
 Figure 3.8 – Diagramme de cas d’utilisation déclaration des impôts

Le tableau suivant décrit le cas d’utilisation "déclarer impôts".

Table 3.4 – Description de cas d’utilisation "déclarer impôts"

Cas d’utilisation Déclarer impôts

Acteur Administrateur
Pré-condition un contribuable clique sur le bouton pour dé-
clarer
Post-condition une déclaration d’impôts est ajoutée dans la
base
Scénario-nominale le contribuable remplie les formulaires de dé-
claration et la valide.
Exception Annuler la procédure à cause des informa-
tions manquantes ou erronées, ou coupure de
connexion

3.3.2 Diagramme d’activités module déclaration des impôts

La figure 3.9 présente le diagramme d’activité pour le module déclaration des impôts.

46
 Figure 3.9 – Diagramme d’activité du module déclaration des impôts

3.3.3 Diagramme de séquences module déclaration des impôts

Le diagramme de séquences suivant 3.10 décrit l’enchainement des actions qui se déroulent
dans notre système lors d’une déclaration.

Figure 3.10 – Diagramme de séquences de l’interaction déclaration des impôts

47
3.4 Diagramme des classes
Un diagramme de classes dans le langage de modélisation unifié (UML) est un type de
diagramme de structure statique qui décrit la structure d’un système en montrant le système
de classes , leurs attributs, les opérations (ou) les méthodes et les relations entre les classes
[12]. C’est une structure abstraite de notre base de données. les classes seront transformer en
objet, les opérations en méthodes.
Notre système OnImpôts est basée sur le contribuable, il peut être une personne physique,
ou bien une personne morale. Un contribuable est identifié par un numéro d’identification
fiscal (NIF). Les informations indispensables à connaitre à propos un contribuable sont :
son numéro d’affiliation en CNSS, sa nationalité, son adresse, son login et son mot de passe
quelque soit sa catégorie.
Si elle est une personne physique, elle a encore, un CIN, un nom, un prénom, une date
de naissance, une profession, une état civil, un nombre des enfants en charge quoi qu’ils
soient handicapés ou non. Si c’est une personne morale, elle a un numéro de registre de
commerce, un raison social , une date de début d’activité, un secteur d’activité, une activité,
un chiffre d’affaire, un régime d’impôts, un code TVA, un assujettissement TVA, un fait
générateur de TVA, une périodicité d’activité, une périodicité de déclaration d’impôts et un
assujettissement d’impôts.
La personne physique doit déclarer ses impôts sur les revenus, ce dernier contient les bénéfices
commerciaux et industriels, les bénéfices des professions non commerciaux, les bénéfices des
activités agricoles et du pêche, les revenus immobiliers, et toutes autres frais et honoraires.
La personne morale doit déclarer les impôts sur les sociétés qui contiennent le valeur de stock
initial au début de l’exercice, la valeur du stock à la fin de l’exercice, la valeur des achats de
l’exercice, le chiffre d’affaire à l’exportation, le chiffre d’affaire globale TTC, le chiffre d’affaire
golbale hors taxe provenant des activités de services et des activités non commerciales, le
chiffre d’affaire globale hors taxe provenant des activités de consommation sur place, les
montants des primes, le résultat comptable, le résultat fiscal, les bénéfices déduits au titre
de l’exploitation ou du réinvestissement, les bénéfices et recettes non imposables, les impôts
dû, le minimum d’impôt en tenant compte des avantages fiscaux, les paiements des acomptes
provisionnels, les pénalités exigibles sur les bénéfices exonérés non déclarés, les taxes de
visites, les prélèvement sur fonds d’intéressement du personnel non réparti, et le TVA.
De Plus, une personne morale doit déclarer ses loyers, qui ont un numéro de loyer, une adresse,

48
une date de début de contrat, une date de fin de contrat, et un prix brut. En fin, elle doit
déclarer ses employés, qui ont, un numéro, une poste, ,les dates début et fin de service, le
salaire brut, les privilèges en nature, le total de revenu brut imposable, le revenu investi, les
montants réduites, et les montant net payé.
Le contribuable doit effectué une déclaration d’impôts, chaque déclaration a un type, et
une date, et spécifie si elle est obligatoire ou bien forfaitaire. Une déclaration concerne un
exercice, ce dernier a un code, une date de clôture, et un cadre légale. Un contribuable peut
faire plusieurs déclaration d’impôts. Une déclaration concerne un seul exercice. Le symbole"+"
qui se situe devant les attribues et les méthodes, signifie que ces sont public. La figure 3.11
ci-dessous illustre le diagramme de classe de notre système.

49
50
Figure 3.11 – Diagramme des classes pour la plateforme OnImpôts
3.5 Conclusion
Dans ce chapitre nous avons pu présenter notre solution conceptuelement. Nous avons
élaborer les modèles conceptuels nécessaires pour la spécification du système. Nous avons
utilisé le langage unifié UML. Dans le chapitre suivant, nous présenterons la réalisation de
notre système après avoir effectuer les choix technologiques et l’architecture physique.

51
Chapitre 4

Construction et transition

Après avoir élaborer le modèle conceptuel de notre système, nous procédons maintenant
à les implémenter. Dans ce chapitre, nous présentons les itérations de la phase construction
et la phase transition de notre projet.

4.1 Implémentation du Backend

En suivant notre architecture prédéfini précédemment, nous divisons, notre application,
en deux grandes parties, la partie serveur qui représente le back-end, et la partie client qui est
le front-end. Notre Back-end est développé en Java, nous utilisons, la framework Spring Boot,
version 2.2.0. En développons un projet à l’aide des Framework de développement, la phase
de configuration de l’environnement de travail et les choix des dépendances et bibliothèques,
est très importante et délicate. Nous définissons dans cette partie, les configurations et les
dépendances de notre application. En utilisant la Framework Hibernate et le Java Persistant
API (JPA), il est trop facile, de créer et gérer les bases des données. Il suffit de créer le schéma,
et configurer notre Framework Hibernate. Puis, cette dernière nous fera l’affaire de création
des tables et les attributs, même de gérer les relations entre les tables de notre base. Tout ça
se fait par analogie à nos classes et grâce aux annotations(@Entity, @Table, @ManyToMany,
etc). Nous gérons notre base à l’aide du Mysql WorkBench, nous avons créer le schéma en
lui donnant le nom "declarationonimpots".
La création d’un projet Spring Boot, se fait à l’aide de spring boot initializer, c’est un
générateur des projets, qui crée pour nous un projet en lui spécifiant les dépendances voulu. Il
configure pour nous, le fichier Pom.xml qui contient toutes les dépendances du projet avec ses
versions. Il est possible de modifier ce fichier ultérieurement manuellement en cas de besoin.

52
Comme dépendances nous avons choisi initialement les dépendances suivantes(web, Mysql,
Jpa, hibernate, rest, security, etc.) La configuration du fichier application.proprities est un
point clés pour un projet spring boot. Il contient l’url du serveur base de données, avec le
nom de la base, le mot de passe avec lequel il se connecte sur le serveur, les configurations
du Hibernate et JPA. Avec le port sur lequel le serveur web se connecte.
Nous commençons par la création des entités, la déclaration des attributs, et puis la géné-
ration des getters et les setters, et enfin les constructeurs. L’étape suivante est la création des
repositories.Les repositories sont des interfaces héritant de l’interface Repository. L’objectif
de ces interfaces consiste à rendre la création de la couche d’accès aux données (requêtes
SELECT, UPDATE...) plus rapide.
On n’est donc pas obligés d’écrire des requêtes supplémentaires pour retrouver une entité,
par exemple, par son identifiant ou de retrouver toutes les entités disponibles. Les méthodes
findById() et findAll() sont là pour cela. En plus, on peut utiliser les méthodes liées au CRUD
(Create, Read, Update, Delete) sans aucun effort supplémentaire.
En outre, la recherche des éléments par des simples clauses WHERE est possible grâce au
modèle findByName() où "Name" signifie l’attribut name de l’entité qu’on veut récupérer.
On peut également créer des requêtes plus complexes. Pour cela, on emploiera l’annotation
@Query directement au-dessus de la méthode qui doit exécuter la requête. On privilégiera
cette technique dans notre application de test à cause de sa facilité de compréhension. Les
requêtes seront écrites en JPQL(Java Persistence Query Language).
Une fois nous avons créer les interfaces repositories, nous définissons les interfaces des
services à utiliser. Ces services sont implémentés pour définir le comportement exacte pour
chaque méthode. En fin, nous déclarons le contrôleur qui va consommer ces méthodes à
travers des requêtes HTTP. Aussi, le contrôleur contient les valeurs des Mapping avec le
navigateur pour chaque méthode.

4.1.1 Itération 1 : module inscription

La première itération, pour la phase de construction, comme pour la phase d’élaboration,

contient le module d’inscription. Les entités qui touchent ce module sont, Contribuable.java,
depuis laquel héritent les entités personnePhysique.java et personneMorale.java. Aussi l’entité
employée.java, est une spécification de l’entité de personneMorale. Par suite, nous créons les
services, et les contrôleurs de ces objets. Pour tester ce module nous avons utiliser l’outils

53
Postman. Les objets sont représenté dans cette étape sous forme des fichiers JSON. La figure
4.1 représente un exemple de test pour ce module. Pour faire une inscription, c’est la méthode
addContribuable qui est utilisé. Le code de retour 200, signifie que le test a réussit.

Figure 4.1 – Test de la méthode addContribuable à l’aide de Postman

De même la méthode addPersonnePhysique, ou bien addPersonneMorale va être invoquer.

Les figures représentent respectivement les tests de ces deux méthodes à travers Postman.

54
 Figure 4.2 –

Figure 4.3 –

4.1.2 Itération 2 : module gestion compte

Le module gestion du compte Contribuable touche aussi les mêmes entités que le module
inscription, mais il invoque des méthodes différentes. Puisque un contribuable peut modifier

55
ses informations à travers la méthode update. L’administrateur aussi peut utiliser la même
méthode pour mettre à jours le profil d’un contribuable. La figure 4.4représente le test de
cette méthode à travers l’outils Postman.

Figure 4.4 – Test de la méthode updateContribuable avec de Postman

4.1.3 Itération 3 : module déclaration des impôts

Le module déclaration des impôts, touche toutes les entités du système. Pareil aux mo-
dules précédentes. Nous créons les entités, les repositories, les services et les contrôleurs. le
test des api de ce module donne les résultats suivantes.

56
 Figure 4.5 – test de module declaration impôts à travers Postman

4.2 Implémentation du Frontend

Notre partie cliente est développé avec la plateforme Angular et programmé en Types-
cript. Grâce à Node.JS, nous pouvons, généré notre projet front-end. NPM nous permet de
gérer les paquets et les dépendances. Chaque module de la partie, peut être généré après en
utilisant l’invite de commande, ou bien à l’aide du terminal intégré en Visual Studio Code.
La première étape après la génération du projet, est la création des modèles. Ces derniers
doivent être conforme aux entités déclarés auparavant dans la partie back-end. Puis, nous
générons les modules de notre application. Chaque module créer contiendra un fichier ts,
qui est responsable du comportent du composant, un fichier css qui définit les styles css, et
enfin un fichier HTML qui englobe la page HTML du composant. Enfin, nous définissons
les services pour chaque composant. Les composants ne doivent pas extraire ou enregistrer
des données directement et ils ne doivent certainement pas présenter de fausses données. Ils
doivent se concentrer sur la présentation des données et déléguer l’accès à un service.
Dans cette phase, nous avons créer un Service pour chaque classe de l’application. Au
lieu de créer ce service avec "new", nous ferons confiance à l’injection de dépendance Angular
pour l’injecter dans le constructeur "Component". Les services sont un excellent moyen de
partager des informations entre des classes qui ne se connaissent pas. La programmation

57
basée sur les patrons de conception, nous facilite la vie en tant que développeurs, citons
par exemple l’utilisation du concept Observable en développons en Angular. Observable est
l’objet de base de la programmation réactive. C’est lui qui va nous permettre de créer des
observables. Subscribe prend en paramètre l’observateur, qui est une simple fonction qui
recevra les valeurs émises par l’observable. Subscribe peut également prendre deux autres
arguments : une fonction appelée en cas d’erreur, et une autre appelée une fois l’observable
fini. La méthode map d’Observable prend des valeurs en entrée, les transforme et les renvoie
en sortie. Il contient aussi les modules suivantes :
• le module HttpClient.
• le module de gestion des routes, lorsque l’URL change
• la gestion des formulaires, lorsque l’utilisateur saisit des valeurs dans des champs de
saisie.
Le décorateur @Injectable() est un décorateur un peu particulier. Il ne permet pas l’injection
à proprement parlé, mais plutôt d’initialiser un contexte de détectabilité. Si nous injectons
dans un de nos services ( sans ce décorateur) un autre service, le moteur d’injection retournera
une erreur. Angular conseille de toujours mettre cette annotation sur un service même si nous
n’utilisons pas les injections dans notre service afin d’éviter de se poser la question plus tard
[25].
Les décorateurs @Component, @Pipe, et @Directive sont des sous classes de @Injectable().
Ces décorateurs ajoutent des MetaDatas au code JavaScript transpilé à partir de nos fichiers
TypeScript. Par défaut, le compilateur TypeScript rejette toutes les meta-données. Pour
que ces metadatas soient integrées au JavaScript, l’option emitDecoratorMetadata doit être
à true dans votre fichier tsconfig.json de votre projet. Angular-CLI a dèjà configuré votre
tsconfig.json pour les prendre en charge.
L’un des énormes avantages d’utiliser Angular est de pouvoir créer des "single page ap-
plication" (SPA). Sur le Web, ces applications sont rapides et lisses : il n’y a qu’un seul
chargement de page au début, et même si les données mettent parfois du temps à arriver, la
sensation pour l’utilisateur est celle d’une application native. Au lieu de charger une nouvelle
page à chaque clic ou à chaque changement d’URL, nous remplaçons le contenu ou une partie
du contenu de la page : nous modifions les components qui y sont affichés, ou le contenu de
ces components. Nous accomplissant tout cela avec le "routing", où l’application lit le contenu
de l’URL pour afficher le ou les components requis.
Angular possède un module appelé Router pour gérer le routage côté client [29]. Pour

58
utiliser le routage dans notre application Angular, il est nécessaire d’effectuer une petite
configuration. La première chose a faire consiste à configurer la base href dans le DOM. Le
routeur utilise l’état de l’historique de navigation du navigateur pour la navigation et l’inter-
action de l’URL. Cela permet essentiellement aux URL d’être utilisées dans une application
client sans déclencher réellement une nouvelle requête à distance. Le code client peut alors
fonctionner contre ces changements d’état et prendre des décisions sur le routage.
Pour cela nous allons ajouter une balise <base> dans la partie ’head’ de notre fichier
index.html de la manière suivante : <base href="/">.
La prochaine chose que nous devons faire est de créer des routes. Faisons-le dans un
nouveau fichier nommé app.routing.ts.
Nous allons tout d’abord importer le module Routes situé dans le paquet ’router’ d’An-
gular. Nous allons créer une variable ’appRoutes’ de type Routes qui sera un tableau. A
l’intérieur pouvons lister les différentes routes de notre application. Chaque élément de ce
tableau est un objet composé de deux propriétés : ’path’ et ’component’. Dans ’path’ nous
mettons l’URL sans ajouter de ’/’ car le router gère la construction de l’URL. Et dans ’com-
ponent’ nous indiquons le composant a afficher.
Après avoir listé toutes nos routes, il reste à indiquer à app.module.ts l’existence de
cette liste. Toujours dans le fichier app.routing.ts, nous importons le module de routeur
qui se trouve également dans le paquet ’router’ d’Angular. Et nous ajoutons une variable
que le nous nommons ’routing’ précédé de la mention ’export’. Cette variable sera égale a
la fonction RouterModule.forRoot qui prend en paramètre un ensemble d’objets de routes.
Nous lui passerons donc notre variable ’appRoutes’.
La dernière chose que nous devons faire est de passer au fichier app.module.ts et d’ajouter
une déclaration d’importation pour le routage. Nous, donc importerons notre variable routing,
et l’ajouterons dans notre liste d’imports dans @NgModule.
Avec cela, notre appModule est conscient des routes que nous avons mis en place et est prêt
à commencer à les traiter. Il est également configuré pour utiliser les directives RouterModule
et les services provenant du RouterModule. Maintenant, une fois terminée toutes ces étapes,
il nous reste que l’écriture des pages HTML, qui nous donne l’allure finale du projet. Dans
les parties qui suivent nous présentons les résultats.

59
4.2.1 Itération 4 : module inscription

Dans cette itération, comme pour les précédentes nous commençons par le module, ins-
cription. La figure 4.6 est l’interface qui permet aux utilisateurs de s’authentifier s’il est déjà
inscrit ou bien de faire une inscription. Il doit spécifier s’il est une personne morale ou bien
une personne physique.

Figure 4.6 – L’interface principale pour le module inscription

Cette interface permet l’utilisateur de se connecter au système s’il est déjà inscrit„ en
entrant son login et son mot de passe. Si non, l’utilisateur peut choisir l’inscription dans
le système. Lorsqu’il clique sur le bouton "Inscription", il doit préciser s’il est une personne
physique ou bien une personne morale comme indique la figure 4.7.

60
 Figure 4.7 – Interface de choix du profil pour l’inscription

Selon le profil choisi, un formulaire d’inscription s’affiche pour être rempli. La figure 4.8
présente le formulaire d’inscription pour une personne physique.

Figure 4.8 – L’interface d’inscription pour une personne physique

La figure 4.9 présente l’interface d’inscription pour une personne morale.

61
 Figure 4.9 – L’interface d’inscription pour une personne morale

Une fois le contribuable a terminé son inscription, l’administrateur doit la valider pour
que ce premier peut se connecter avec les identifiants choisi. La figure 4.10 présente l’interface
de validation des inscription faite par l’administrateur pour les personnes morales, pareil pour
les personnes physiques.

Figure 4.10 – L’interface de validation des inscription des personnes morales par l’adminis-
trateur

62
4.2.2 Itération 5 : module gestion compte

La cinquième itération concerne le module gestion du compte d’un contribuable. Un

contribuable peut mettre à jours son profil pour modifier une ou plusieurs informations.
L’administrateur aussi peut faire ceci en cas de besoin. La figure 4.11 présente l’interface
graphique pour ce faire.

Figure 4.11 – L’interface de gestion des comptes des contribuables

4.2.3 Itération 6 : module déclaration des impôts

Le module déclaration des impôts, est traité pendant la dernière itération de la phase de
construction. Dans ce module le contribuable se connecte et choisi de déclarer ses impôts.
Selon son profil, il sera renvoyé vers le formulaire convenable.
Si le contribuable est une personne morale donc il peut déclarer trois types d’impôts, soit
il déclare des loyers, soit des employées, soit les impôts sur les revenus des sociétés. La figure
4.12 présente le formulaire de déclarations des impôts sur les sociétés.

63
 Figure 4.12 – Interface de déclaration des impôts sur les sociétés

La figure 4.13 présente le formulaire de déclarations des loyers.

Figure 4.13 – Interface de déclaration des loyers pour les personnes Morale

La figure 4.14 présente le formulaire de déclarations des employés.

64
 Figure 4.14 – Interface de déclaration des employées pour les personnes Morale

4.3 Itération 7 : Transition

Le but de la phase de transition est de procurer le logiciel à la communauté d’utilisateurs
[12] Après que le produit ait été donné à l’utilisateur, il est généralement nécessaire de
développer de nouvelles versions, de corriger certains problèmes ou de finir certaines choses
postposées. Il s’agit d’effectuer les bêtas tests pour valider le nouveau système auprès des
utilisateurs et le déploiement de celui-ci. La phase de transition se termine par le jalon «
livraison du produit » ou par une nouvelle itération. Pour notre cas, la solution est un
modèle générique qui va être passer par des adaptations et des autres configuration avant de
passer à la main du client final. Pour cela, nous avons décider de mettre toute la plateforme
dans un conteneur qui nous assure le bon fonctionnement même en cas de changement de
l’environnement. Nous avons choisi Docker comme plateforme de containérisation. Une image
container est un ensemble de processus logiciels léger et indépendant, regroupant tous les
fichiers nécessaires à l’exécution des processus : code, runtime, outils système, bibliothèque
et paramètres. Ils peuvent être utilisés pour exécuter des applications Linux ou Windows.
Vue que le temps du stage est trop serré, nous laissons cette opération comme perspectives
pour notre projets.

65
4.4 Conclusion
Dans ce chapitre nous avons pu implémenter nos modèle et donner une solution logicielle
exécutable, nous avons essayer de nos mieux de vérifier le maximum des besoins fonctionnels
et non fonctionnels. A la fin de ce chapitre nous avons déployé notre solution dans un container
pour qu’il garde son état de fonctionnement même en changeant d’environnement d’exécution.

66
Conclusion générale

Ce projet est la fruit du cycle d’ingénieur en informatique, spécialisé en génie logiciel.

Il nous a permis de valider nos connaissances et pré-requis. Il est une initiation à la vie
professionnelle, puisqu’il se déroule au sein d’ArabSoft qui est une société dénommé dans le
domaine de développement informatique en Tunisie depuis 1985.

ArabSoft, travaille sur les systèmes e-gov, le sujet principal de notre projet. Une plateforme
des télé-procédures est un service qui offre une États à ces citoyens. Le service étudié pour
notre cas est, la déclaration des impôts en ligne.

Les systèmes e-gov sont tellement délicats, ils évolues trop vite et ont tendances à chan-
ger d’une façon répétitive. Les solutions à proposer pour ces systèmes e-gov, vaut mieux être
générique, adaptable et configurable, puisque ça dure beaucoup du temps pour les élaborer
et ça change rapidement. Notre solution vérifie ce contrainte, en suivant l’approche MDA,
nous garantissons la valorisation du savoir faire. Les technologies et les outils nous aident
à gagner du temps et d’effort. OnImpôts offre aux utilisateurs la possibilité de déclarer ses
impôts en ligne, à travers un canal sure et disponible tout le temps. Nous avons proposer
une solution générique et adaptable pour chaque États et pour chaque besoin.L’approche de
programmation générique qui nous avons suivi, impose d’élaborer un modèle initiale, puis
nous sortant deux volets, une contient le logique du métier qui a une très faible probabilité
pour changer, et l’autre volets contient les paramètres. a la fin nous obtiendrons un système
avec deux interfaces, l’une pour le paramétrage et l’autre pour l’exploitation. Cet enchaine-
ment de travail applique le design pattern "Reflexivity". Notre solution proposé, n’est que la
début d’un grand projet, qui nécessite une équipe pour le mettre en œuvre. Par contre nous
avons déjà défini l’architecture et les modèles à suivre dans ce cas. Donc nous avons élaborer
le modèle initiale. Nous avons suivi les méthodologies et les approches qui nous assurent
la mise en œuvre de nos idées. Notre systèmes OnImpôts, offre aux citoyens d’un pays de
déclarer ses impôts en ligne, en se débarrassant des procédures administrative ennuyantes.

67
 Ce projet nous a permis de se confronter à tout le cycle de vie d’un logiciel, et par suite de
jouer tous les rôles qu’un ingénieur informatique peut le pratiquer pendant ce cycle. C’étais
une très importante période pour nous, pleine d’expériences et pleine de défis. Parmi les
expériences que nous avons la chance d’avoir sont la gestion d’un projet informatique depuis
la détection des besoin jusqu’au la livraison finale, le travail en équipe et en environnement
professionnel et réelle, et aussi l’apprentissage des nouveaux notions. Les plus importants
défis sont la sensibilité du métier traiter et sa difficulté, le travail sous stress puisque la durée
est limitée et l’auto-formation en parallèle avec ce travail.
Même si nous avons rencontrer quelques difficultés, mais nous avons pu les dépassées
finalement. Nous pensons que la durée du stage été un peu courte pour pouvoir s’approfondir
vraiment dans chaque phase de cycle de vie de la solution. Comme perspectives pour ce projet,
nous proposons de compléter les fonctionnalités manquantes et d’évoluer vers la version
générique et configurable, pour bénéficier des approches suivi et au design pattern choisi et
achever l’idée principale de la solution proposée.

68