RapportJulesIAIL2 Final Du Dimanche

INSTITUT AFRICAIN D’INFORMATIQUE CLOUD OF ENGINEERS FOR
REPRESENTATION DU CAMEROUN SOCIAL DEVELOPMENT S.A
B.P: 3719 Yaoundé B.P: 3719 Yaoundé
Tel: (+237) 242 72 99 58 Tel: (+237) 697 892 096
Site Web: https://iaicameroun.com/ Site Web: https://cesd-sa.com/
E-mail : iaicameroun@yahoo.fr E-mail : contact@cesd-sa.com
RAPPORT DE STAGE
THEME : MISE SUR PIED D’UN SYSTÈME

D’ADRESSAGE NUMÉRIQUE
Stage effectué du 02 Juin au 30 Septembre 2021, en vue de l’obtention du Diplôme de

Technicien Supérieur (DTS) option Systèmes et Réseaux
Rédigé par :
MEKONTSO Jules Auffred,
Étudiant en License 2 à l’IAI-Cameroun
Sous la supervision
Académique de : Et Professionnelle de :
M. NDOUMI Nynke François M. MOMO Arnaud

Ingénieur informaticien Architecte des SI et PDG de CESD S.A
Année Académique 2020-2021

THÈME : MISE SUR PIED D’UN SYSTÈME
MEKONTSO Jules Auffred étudiant en deuxième année à l’IAI-Cameroun, centre

d’excellence technologique PAUL BIYA. Année Académique : 2020-2021
II
Dédicace
TOUTE LA FAMILLE
MEKONTSO

III
Remerciements
La réalisation de ce rapport de stage a été possible grâce au concours de plusieurs

personnes à qui nous souhaitons témoigner toute notre gratitude. De ces personnes, nous avons
reçu de l’aide tant sur le plan financier que sur le plan moral. Nous adressons nos sincères
remerciements a toutes ces personnes, plus particulièrement à :
✓ Monsieur Armand Claude ABANDA, Représentant Résident de l’institut Africaine

d’informatique (IAI-Cameroun), qui m’a permis d’intégrer cette prestigieuse école ;
✓ Monsieur MOMO Arnaud, PDG de Cloud Of Engineers For Social Development S.A.
(CESD SA) et Encadreur professionnel pour sa disponibilité, son aide et son indulgence
à notre endroit tout au long de notre stage ;
✓ Monsieur NDOUMI Nynke François, Encadreur académique pour sa disponibilité
incontestable et ses conseils ;
✓ Monsieur TCHOFFO Jean Jaurès Développeur chez Cloud Of Engineers For Social
Développent S.A. (CESD SA) pour le temps qu’il nous a consacré tout au long de
l’expérience enrichissante qui a été le nôtre en sachant répondre à nos questions ;
✓ Tout le personnel de l’institut Africaine d’informatique (IAI-Cameroun) pour les

enseignements reçus ;
✓ Tout le personnel de Cloud Of Engineers For Social Development S.A. (CESD SA) ;
✓ Toute la famille MEKONTSO pour l’opportunité qu’elle m’a offerte, son éducation et
son soutien moral et financier ainsi que l’amour et l’affection qu’ils m’ont toujours
accordés ;
✓ Tous mes camarades de l’institut Africaine d’informatique (IAI-Cameroun) ;

IV
Sommaire
DÉDICACE .................................................................................................................. III
REMERCIEMENTS .................................................................................................... IV
SOMMAIRE.................................................................................................................. V
LISTE DES TABLEAUX ......................................................................................... VIII
LISTE DES FIGURES .................................................................................................. X
LISTE DES ABRÉVIATIONS ................................................................................. XIII
RÉSUMÉ ................................................................................................................... XIV
ABSTRACT ................................................................................................................XV
INTRODUCTION GÉNÉRALE .................................................................................... 2
PARTIE I : PHASE D’INSERTION .............................................................................. 3
INTRODUCTION .......................................................................................................... 4
I. ACCUEIL ET INSERTION DANS L’ENTREPRISE ................................ 5
II. PRESENTATION DE LA STRUCTURE .................................................. 5
III. RESSOURCES MATERIELLES ET LOGICIELLES DE CESD SA .... 11
IV. PRESENTATION DU THEME .............................................................. 14
CONCLUSION ............................................................................................................ 15
PARTIE II : PHASE TECHNIQUE ............................................................................. 16
DOSSIER I. CAHIER DES CHARGES ............................................................... 17

V
INTRODUCTION ........................................................................................................ 18
I. CONTEXTE ET JUSTIFICATION DU PROJET ..................................... 19
II. OBJECTIFS DU PROJET ........................................................................ 19
III. CIBLES .................................................................................................... 20
IV. EXPRESSION DES BESOINS ............................................................... 20
V. INTERVENANTS .................................................................................... 22
VI. ETUDE FINANCIERE DU PROJET ..................................................... 22
VII. PLANIFICATION DU PROJET ........................................................... 25
VIII. CONTRAINTES ................................................................................... 27
IX. LIVRABLES ........................................................................................... 27
CONCLUSION ............................................................................................................ 28
DOSSIER II. ANALYSE ...................................................................................... 29
INTRODUCTION ........................................................................................................ 30
I. DESCRIPTION DE L’EXISTANT ........................................................... 31
II. CRITIQUE DE L’EXISTANT ................................................................. 32
III. PROBLEMATIQUE ................................................................................ 33
IV. PRESENTATION DE LA SOLUTION PROPOSE ............................... 33
V. PRÉSENTATION DE LA DÉMARCHE D’ANALYSE ......................... 34
VI. MODÉLISATION DE LA SOLUTION ................................................. 39
CONCLUSION ............................................................................................................ 57
DOSSIER III. CONCEPTION .............................................................................. 58
INTRODUCTION ........................................................................................................ 59

VI
I. CAPTURE DES BESOINS TECHNIQUE ................................................ 60
II. CONCEPTION GENERIQUE ................................................................. 70
CONCLUSION ............................................................................................................ 71
DOSSIER IV. RÉALISATION ............................................................................. 72
INTRODUCTION ........................................................................................................ 73
I. CONCEPTION PRELIMINAIRE.............................................................. 74
II. CONCEPTION DETAILLEE ................................................................... 77
III. CHOIX TECHNOLOGIQUE .................................................................. 78
IV. CODAGE ET TEST ................................................................................ 80
CONCLUSION ............................................................................................................ 90
DOSSIER V. GUIDE D’UTILISATION .............................................................. 91
INTRODUCTION ........................................................................................................ 92
I. GUIDE DE DÉPLOIEMENT .................................................................... 93
II. GUIDE D’UTILISATION ........................................................................ 93
CONCLUSION .......................................................................................................... 100
CONCLUSION GÉNÉRALE .................................................................................... 101
BIBLIOGRAPHIE ......................................................................................................... ii
WEBOGRAPHIE .......................................................................................................... iii
TABLE DES MATIERES ............................................................................................. iv
ANNEXES .................................................................................................................... xi

VII
Liste des tableaux
Tableau 1-les services de CESD SA .............................................................................. 6
Tableau 2-les produits de CESD SA .............................................................................. 7
Tableau 3-ressources matérielles .................................................................................. 11
Tableau 4-ressources logicielles ................................................................................... 12
Tableau 5-estimation du coût du projet ........................................................................ 24
Tableau 6-planification des tâches ............................................................................... 25
Tableau 7-critique de l'existant..................................................................................... 32
Tableau 8-etude comparative entre UML et Merise..................................................... 34
Tableau 9-les processus UML ...................................................................................... 37
Tableau 10-Éléments du diagramme de cas d'utilisation ............................................. 39
Tableau 11-les acteurs et cas d'utilisation du système ................................................. 40
Tableau 12-description textuelle du cas d'utilisation s'authentifier .............................. 44
Tableau 13-description textuelle du cas d'utilisation demande d'adresse..................... 45
Tableau 14-description textuelle cas d'utilisation rechercher une adresse ................... 45
Tableau 15-Eléments constitutif du diagramme de séquence ...................................... 46
Tableau 16-elements constitutif du diagramme d'activité ............................................ 54
Tableau 17-comparaisons des architectures physiques ................................................ 60
Tableau 18-élement constitutifs d'un diagramme de classe ......................................... 64
Tableau 19-liste des attributs et classes de notre système ............................................ 65

VIII
Tableau 20-élément constitutif du diagramme d'état transition ................................... 67
Tableau 21-elements constitutifs du diagramme des composants ................................ 74
Tableau 22-les outils utilises ........................................................................................ 87
Tableau 23-les langages de programmation utilisés ..................................................... 89

IX
Liste des figures
Figure 1-plan de localisation CESD SA ....................................................................... 10
Figure 2-structure hiérachique de l'entreprise .............................................................. 11
Figure 3-architecture réseau de CESD SA ................................................................... 13
Figure 4-Diagramme de gantt du projet ....................................................................... 26
Figure 5-système de numérotation continu .................................................................. 31
Figure 6-système de numérotation métrique ................................................................ 32
Figure 7-le processus 2TUP ......................................................................................... 38
Figure 8-formalisme d'un diagramme de cas d'utilisation ............................................ 40
Figure 9-Représentation du diagramme de cas d’utilisation utilisateur ....................... 42
Figure 10-Représentation du diagramme de cas d’utilisation globale ......................... 43
Figure 11-formalisme diagramme de sequence ............................................................ 48
Figure 12-formalise du diagramme de sequence .......................................................... 48
Figure 13-diagramme de séquence s'authentifier ......................................................... 49
Figure 14-diagramme de séquence demander une adresse........................................... 50
Figure 15-diagramme de séquence rechercher une adresse ......................................... 51
Figure 16-diagramme de séquence s'inscrire ................................................................ 52
Figure 17-diagramme de séquence ces d'utilisation naviguer vers une adresse ........... 53
Figure 18-formalisme du diagramme d'activité............................................................ 54
Figure 19-diagramme d'activité, cas d'utilisation demande d'adresse .......................... 56

X
Figure 20-architecture micro service source :
https://www.redhat.com/fr/topics/microservices/what-are-microservices ............................... 62
Figure 21-architecture physique de l'application .......................................................... 63
Figure 22-formalisme du diagramme de classe ............................................................ 64
Figure 23-diagramme de classe de l'application ........................................................... 67
Figure 24-formalisme du diagramme d'état transition ................................................. 68
Figure 25-diagramme d'état transition d'une adresse ................................................... 69
Figure 26-prototype de l'Application ........................................................................... 70
Figure 27-formalisme du diagramme des composants ................................................. 75
Figure 28-formalisme du diagramme des composants ................................................. 75
Figure 29-diagramme des composants ......................................................................... 75
Figure 30-elements constitutifs du diagramme de déploiement ................................... 76
Figure 31-formalisme du diagramme de déploiement.................................................. 76
Figure 32-diagramme de déploiement du système ....................................................... 77
Figure 33-modèle physique de données ....................................................................... 78
Figure 34-architecture MVC ........................................................................................ 80
Figure 356ARCHITECTURE MVVM ........................................................................ 82
Figure 36-fonctionnement d'un web service ................................................................ 84
Figure 37-architecture micro services .......................................................................... 87
Figure 38-inscription à Myaddress ............................................................................... 94
Figure 39-connexion à myaddress ................................................................................ 95
Figure 40-génération d'adresse ..................................................................................... 96

XI
Figure 41-Rechercher une adresse................................................................................ 97
Figure 42-navigation dans myadresse .......................................................................... 98
Figure 43-navigation dans myadresse via l'onget navigation ....................................... 99

XII
Liste des abréviations
2TUP : Two Track Unified Process

AGL : Atelier de Génie Logiciel
BD : Base de Données
CESD : Cloud of Engineers for Social Development
HTTP : HyperTextTrasfert Protocol
IAI : Institut Africain d’Informatique
IHM : Interface Homme Machine
IIS : Internet Information Service
IT : Information Technology
JSON : JavaScript Object Notation
MVC : Model Vue Controlleur
MVVM : Model View View-Model
OS : Operating System
PDG : Président Directeur Général
REST : Representationnal State Transfer
S.A : Société Anonyme
SI : Système d’Information
SIG : Système d’information Géographique
SGBD : Système de Gestion des Base de Données
SGBDS : Système de Gestion des Base de données Spatial
SOAP : Simple Object Acces Protocol
SQL : Structured Query Language
TIC : Technologie de l’information et de la Communication
UML : Unified Modeling Language
WSDL : Web Service Description Language
XAML : eXtensible Application Markup Language

XIII
Résumé
De nos jours, toutes les villes subissent une croissance exponentielle, le nombre
d’habitant et d’habitation ne cesse d’augmenter. Cette urbanisation rapide et mal contrôlée
aggrave les difficultés d’orientation et de localisation. Les populations recourent à des noms
usuels de lieux même là où les rues sont dénommées. Avec l’avènement de la COVID-19 qui
impose les mesures de distanciation, les entreprises ont recourt au télétravaille et les citoyens
sont tenu de limiter leurs déplacements. C’est ainsi que les domaines comme le e-commerce
avec la livraison à domiciles et d’autre domaine se sont considérablement développés. C’est
pourquoi il nous a été confié la mission de mettre sur pied d’un système d’adressage
numérique avec une application mobile à l’appui.
L’objectif du travail qui nous a été assigné est de donner la possibilité à n’importe quel
Camerounais de demander une adresse autogénérée avec son téléphone portable tout en
respectant la loi sur l’adressage au Cameroun. Notre système sera capable de transformer des
coordonnées géographiques en une adresse compréhensive. Il sera question pour nous
d’orienter nos recherches sous le thème : mise sur pied d’un système d’adressage
numérique.
Il a donc été question pour nous de mettre sur pied une application mobile cross
plateforme nommée « MyAddress » qui permet aux utilisateurs de demander et de gérer une
adresse pour leur domicile ou leur bureau en nous servant des outils tels que le langage UML
joint au processus 2TUP, l’architecture micro-service et d’autres langages telle que : le C#, le
XAML et le LINQ to SQL. Tout ceci nous a permis de mettre sur pied un système efficace et
sécurisé.
A partir des résultats obtenus, qui sont ceux de permettre aux différents utilisateurs du
système d’obtenir une adresse juste en faisant un clic, nous pouvons noter que, notre application
permettra donc une meilleure orientation des populations, une meilleure gestion urbaine, les
livraisons à domicile optimisées, les interventions plus rapides des pompiers et ambulances.
Mot clé : Adresse, localisation, coordonnées géographiques

XIV
Abstract
Nowadays, all cities are growing exponentially, the number of inhabitants and dwellings
is constantly increasing. This rapid and uncontrolled urbanisation aggravates the difficulties of
orientation and location. People resort to common place names even where streets are named.
With the advent of COVID 19, which imposes distance measures, companies have resorted to
teleworking and citizens are required to limit their outings. As a result, areas such as e-
commerce with home delivery and other areas have developed considerably. This is why we
were given the task of setting up a digital addressing system with a mobile application to support
it.
The objective of the work we have been assigned is to give the possibility to any
Cameroonian to request an autogenerated address with his mobile phone while respecting the
law on addressing in Cameroon. Our system will be able to transform geographical coordinates
into a comprehensive address. We will focus our research on the theme of setting up a digital
addressing system.
We will build a cross-platform mobile application that allows users to request and
manage a home or office address using tools such as UML in conjunction with the 2TUP
process, micro-services architecture and other languages such as C#, XAML and LINQ to SQL.
All this allowed us to build an efficient and secure system.
From the results obtained, which are those of allowing the various users of the system
to obtain an address just by making a click, we can note that, our application will thus allow a
better orientation of the populations, a better urban management, optimized home deliveries,
faster interventions of the firemen and ambulances.
Keyword: Address, urbanisation, digital, location, geographical coordinates

XV
INTRODUCTION GÉNÉRALE
L’expansion spatiale et la croissance démographique ne cesse d’impressionner. Cette

urbanisation rapide et mal contrôlée aggrave les difficultés d’orientation et de localisation.
Aujourd’hui, plusieurs opérations d’adressage ont été lancées pour faciliter la gestion urbaine
et l’orientation des populations. Mais alors, c’est quoi l’adressage ? En effet, l’adressage est un
système d’identification des domiciles, des constructions, des parcelles et des lieux publics.
Ceci favorise le repérage facile autant pour les habitants que pour les visiteurs. Cependant, il
nous a été de contacter que juste quelques lieux dans les plus grandes villes possèdent une
adresse. L’adressage des villes n’est toujours pas effectif et le système utilisé est manuelle et
pas très efficace. Nous nous confrontons donc à la problématique suivante : comment
améliorer le système d’adressage tel qu’existant ? Pour un pays en voie d’émergence,
l’adressage des villes est un aspect très important. C’est dans ce cadre d’étude que s’est inscrit
notre projet de stage académique : Mise Sur Pied D’un Système D’adressage numérique que
nous avons eu l’occasion de mettre en œuvre dans les locaux de CESD SA. Pour mener à bien
ce projet, Nous allons voir tout d’abord l’accueil qui nous a été réservé ainsi que la structure
qui nous a ouvert ses portes. Ensuite, nous définirons les spécifications de base de notre projet
à réaliser ainsi que ses modalités d’exécutions. Par la suite, nous reformulerons clairement par
le biais d’une analyse les réponses à la question « que fait le système ? » ceci en présentant une
étude de l’existant qui sera argumentée par la présentation de ses limites ainsi que la proposition
de solutions. Après cette analyse, nous entrerons dans la conception et la réalisation dans
laquelle seront présentés les diagrammes intervenants ainsi que les différentes architectures et
technologies utilisées en troisième partie. Enfin suivra le guide d’utilisation de notre système.

d’excellence technologique PAUL BIYA. Année Académique : 2020-2021 2
PARTIE I : PHASE D’INSERTION
Résumé
Cette première partie vise à établir un compte rendu à la structure académique de notre
première prise de contact avec l’entreprise ainsi que de notre insertion au sein de cette dernière.
Nous y présenterons l’accueil qui nous a été réservé ainsi que la structure qui nous a ouvert ses
portes.
Aperçu :
Introduction
I. Accueil et insertion dans l’entreprise
1. Accueil dans l’entreprise
2. Intégration dans l’entreprise
II. Présentation de la structure
1. Historique
2. Identification
3. Mission
4. Plan de localisation
5. Organigramme
Conclusion

Introduction
Le terme formation professionnelle regorge deux (02) aspects distincts : Un aspect
théorique qui est purement académique et un aspect pratique qui vise une prise de contact avec
le monde professionnel. Ainsi, un étudiant ayant suivi une formation académique se doit
d’effectuer un stage académique dans une entreprise qui satisfait les critères de sérénité et
d’objectivité afin que son insertion professionnelle soit un succès. Ainsi dit, l’entreprise qui
nous a ouvert ses portes se nomme Cloud of Engineers for Social Development S.A. (CESD
SA). La suite de cette section consistera donc à faire une présentation de cette dernière en
mettant un accent sur son historique, sa situation géographique, sa structure organisationnelle,
ses activités ainsi que ses produits et services. Nous présenterons également les ressources
matérielles dont elle dispose, la problématique qu’elle rencontre et que nous traiterons dans
notre sujet de stage.

I. ACCUEIL ET INSERTION DANS L’ENTREPRISE
Accueil
Le Mercredi 02 Juin 2021 a marqué la date de début de notre stage académique. Dès
07h30 nous nous sommes présentés dans les locaux de l’entreprise où nous avons été reçus par
Monsieur Jean Jaurès TCHOFFO et Monsieur Arnaud MOMO le Président Directeur
Général (PDG) de Cloud of Engineers for Social Development S.A. qui se sont chargés de nous
présenter chaque service de l’entreprise et leurs responsables. Nous avons également bénéficié
d’une séance de briefing sur le règlement intérieur de la structure (horaire de début et de fin,
code vestimentaire, etc.), sur les différentes attitudes à cultiver ainsi que sur les rôles de chaque
responsable dans la hiérarchie de l’entreprise.
Intégration dans l’entreprise
Tout au long de notre phase d’insertion dont la durée a été de deux semaines, il était
question pour nous de nous familiariser avec la structure d’accueil tout en nous rapprochant de
la haute hiérarchie ainsi que toute autre personne s’y trouvant et qui de manière directe ou
indirecte pourrait intervenir dans la réalisation de notre projet. Cela a été un moment de joie,
de bonheur mais plus d’apprentissage pour nous. Nous tenons à préciser que si cette phase a
pleinement réussi, c’est grâce au personnel de CESD SA qui se sont montrés très ouvert à nous
afin de répondre efficacement à nos préoccupations. Au sorti de cette phase d’intégration, un
thème nous a été attribué : Il s’agit de la Mise sur pied d’une application d’adressage des
domiciles des villes du Cameroun.
II. PRESENTATION DE LA STRUCTURE
Historique
Cloud of Engineers for Social Development (CESD S.A.) est une société anonyme au
capital social de 10 000 000 de Francs et disposant d’un conseil d'administration comptant de
nos jours 03 actionnaires. Elle voit le jour en Janvier 2016 sous le nom de Cloud Informations
System avec pour statut juridique « ETS ». En 2018, elle subit une transformation à travers

laquelle elle passe de son statut « ETS » à « S.A. ». Son slogan est : « ensemble façonnons
l’avenir ».
CESD S.A. est une société de services informatiques et géomatiques qui a pour mission
de résoudre au quotidien les problèmes que rencontres les différentes entreprises liées à
l'informatique et à la géomatique quel que soit le domaine d'activité.
Présentation des services
CESD S.A. vise à répondre aux préoccupations technologiques des entreprises en

Afrique. Ainsi, elle propose les services suivants :
Tableau 1-les services de CESD SA
N° Nom du Service Cible Description
1 Géo Business Intelligent Entreprises privées, • Analyse des données

publiques, particuliers géospatiales ;
• Conception et réalisation des

SIG.
2 Intégration de solution Entreprises privées, • Permettent des expériences

publiques, particuliers transparentes et sécurisées
pour vos clients et citoyens,
du back-office au front-
office.
2 Assistance à la maîtrise Entreprises privées, • Étude de faisabilité des

d’ouvrage publiques, particuliers projets IT ;
• Élaboration des cahiers de

charges ;
• Gestion de projets et
Accompagnement.
3 Cybersécurité Entreprises privées, • Évaluation des mises en place

publiques, particuliers des SI ;
• Evaluation du niveau de
sécurité
• Sécuriser les SI des

entreprises

4 Développement Mobile & Entreprises privées, • Conception des applications

Web publiques, particuliers mobiles multiplateformes ;
• Conception et développement
des applications Web
Responsives ;
• Web designer
• Conception et développement
des applications Web
Responsives.
5 Formations, Certifications Entreprises privées, • Formation en Développement

publiques, particuliers Mobile ;
• Formation en développement
web ;
• Formation en Administration
de Bases de données.
6 Audit – conseil- Entreprises privées, • Évaluation des mises en place

Consulting publiques, particuliers des SI ;
• Design des Architectures.
• Choix des meilleures

pratiques et technologies.
Présentation des produits de CESD SA

Tableau 2-les produits de CESD SA
Consommateur
Nom du produit (utilisateur Description
cible)
Application mobile permettant aux clients d’une banque

Banques et d’effectuer des opérations (consulter le solde, l’historique,
établissements faire des virements et des retraits par mobile money)
Flash Money (Mobile de micro finance
Banking) Portail web d’administration pour le back office.

Une plateForme de SMS professionnels avec un core API

Grand public
facile à intégrer, simple et sécuriser
WANTA SMS
Est un portail géo-décisionnelle hautement paramétrable qui

s'intègre parfaitement à vos différents SI et vous permet de
ressortir des KPI (Indicateurs de Performances Clés) pour le
WANTA BI suivi intelligent de votre affaire.
Application de gestion hôtelière permettant à une Structure

hôtelière (hôtel, motel, auberge) de gérer aisément son
CisHotelPro quotidien (réservation en ligne, hébergement, bar-restaurant,

Structure
hôtelière (hôtel, planning de ménage, Comptabilité matière, main courante,
Fiche de police, production des rapports statistiques).
motel …)
Il permet également de booster le taux d’occupation des

chambres.
Cis Pressing Application de gestion automatisée des pressings et

Pressing et
Blanchisseries (dépôt de linge, système de nettoyage,
blanchisserie
facturation, paiement, état statistique)

Progiciel de gestion intégrée et intégrale des structures

sanitaires.
CarePro (Gestion
Hospitalière) Il permet à toutes les structures sanitaires, quelle que soit leur
Structures taille, de faire le suivi informatisé du patient de son entrée
hospitalières jusqu’à sa sortie avec état financier et dossier médical
numérique.
Il est couplé aux outils d’analyse intelligente (Business

Intelligent) pour faciliter la prise de décisions.
Wanta est un concept tout nouveau. C’est une plateforme

futuriste qui va permettre de :
o Rechercher géographiquement un point (Hôtel,

restaurent, hôpital …) ;
Wanta
o Faire une réservation (cas d’hôtel par exemple) ;
o Commander en ligne (cas d’un shoping ou d’un

Grand public resto) ;
o Acheter en ligne (cas d’un billet de voyage pour une

agence) ;
o Gérer ses finances (comptabilité personnelle) ;
o Et tout ceci sur une même plateforme mobile ;
o La révolution de « All in One ».
Plateforme de gestion du système assurance santé permettant

aux assureurs d’offrir la possibilité aux hôpitaux et cliniques
Sociétés
d’assurance et de vérifier l’état et le taux de couverture sanitaire d’un assuré
AsAssure
de courtage afin d’éviter les dépassements de taux.
d’assurance Il permet aussi d’enregistrer les factures des hôpitaux et en
faire des statistiques.

Plateforme de E-commerce pour la promotion et la vente des

produits naturels tels que le miel, les épices, du thé, des fruits
séchés, des aromates, des recettes pour traitement de maladies
à base de produits naturels etc…
CESD SHOP Tout public
Le client passe des commandes, effectue le payement par

Orange money et MTN mobile money avec une possibilité de
se faire livrer à domicile.
Situation géographique
Figure 1-plan de localisation CESD SA

Structure hiérarchique de CESD SA
Figure 2-structure hiérachique de l'entreprise
III. RESSOURCES MATERIELLES ET LOGICIELLES

DE CESD SA
Ressources matérielles
Les équipements matériels dont dispose Cloud of Engineers for Social

Developpment S.A. sont divers et variés. Parmi ces derniers nous pouvons énumérer :
Tableau 3-ressources matérielles
Équipement Marque Description N

ombre
Ordinateur portable et HP, DELL, Les ordinateurs de l’entreprise ont 13

desktop TOSHIBA, principalement trois (3) types de
SAMSUNG, Acer ; système d’exploitation :

Windows 10, Debian, Kali ;
Modem D-Link, Huawei. Modem utiliser pour la connexion 02

internet
Routeur Lynksys Routeur utilisé pour les formations 01
Projecteur U3-830sf Principal outil de formation et de 01

préparation des pré-soutenances
Imprimante DELL 944 Imprimante de haute entreprise 01

multifonction servant à l’impression des rapports et
des documents
Serveur DELL Serveur quad core de 08 go de 01

RAM et 4 disques dure de 01 TO
chacun
Ressources logicielles
Tableau 4-ressources logicielles
Type de logiciel Nom du logiciel Description
Microsoft office 2013, 2016 et 365 Suite bureautique contenant la gamme de

Bureautique
Familiale logiciel Microsoft office.
Windows 7 Professionel, Windows

10 Professionnel, Windows server
Permettant de gérer les ressources matérielles
Système d’exploitation 2008 R2, Windows Server 2012,
et logicielles d’un ordinateur
Windows Server 2012 R2
Microsoft SQL Server 2008 R2,

Microsoft SQL Server 2012,
Systèmes de gestion de base de données des
SGBD Microsoft SQL Server 2016, Oracle
différentes applications développées.
10g Database, Oracle 11g Database,
Oracle 12c Database
Paiement, Gestion de la Suite logicielle permettant la gestion de la paie,

comptabilité, gestion Sage Saari la gestion commerciale et la gestion de la
commerciale comptabilité

Architecture réseau de CESD SA
Schéma suivant présente l’architecture réseau de Cloud of Engineers for Social

Development :
Figure 3-architecture réseau de CESD SA

IV. PRESENTATION DU THEME
Le thème proposé par notre encadrant professionnel est « mise sur pied d’un système
d’adressage numérique ». Nous devrions donc développer une application mobile cross-
plateforme qui sera capable de donner une adresse à un domicile en en transformant des
coordonnées géographiques en une adresse compréhensive en fonction de la commune, du
département dans lequel il se trouve. L’objectif principal étant de permettre aux utilisateurs de
pouvoir obtenir une adresse pour leur domicile ou leur bureau facilement ce qui permettra
d’améliorer le repérage et l’orientation, de faciliter les interventions d’urgence : ambulances,
pompier, police, de faciliter les services urbains, des domaines tel que le e-commerce (livraison
à domicile) et bien d’autres.

Conclusion
Parvenue au terme de cette première partie de notre rapport de stage où il a été question
de faire un compte rendu à l’instance académique de notre insertion en entreprise et faire une
présentation de cette dernière, nous pouvons dire que nous avons été satisfaits par l’accueil
enthousiaste qui nous a été offerte et par la large disponibilité de tout le personnel face à nos
questions ; nous pouvons affirmer sans aucun doute que notre adaptation aux conditions de
travail n’a pas été difficile. Nous comptons ainsi mener à bien l’étude de notre projet qui
consiste en la : Mise Sur Pied d’une application d’adressage des domiciles des villes du
Cameroun ce thème a pour but de résoudre la problématique qui est : comment se retrouver
dans une ville toujours grandissante ? Ceci nous conduit à la prochaine étape de notre rapport
de stage qui sera ainsi consacrée à l’élaboration du cahier des charges conformément aux
exigences académiques et professionnelles

PARTIE II : PHASE TECHNIQUE
PLAN
DOSSIER 1: CAHIER DES CHARGES
DOSSIER 2: D'ANALYSE
DOSSIER 3: CONCEPTION
DOSSIER 4: REALISATION
DOSSIER 5: GUIDE D'INSTALLATION ET

GUIDE UTILISATEUR

DOSSIER I. CAHIER DES CHARGES
Résumé
Le cahier des charges est un document contractuel établit entre le maître d’œuvre et le
maître d’ouvrage qui étale les besoins du client. Il joue le rôle d’étude et de présentation avec
exactitude des exigences formulées par les utilisateurs en ce qui concerne le projet, son
déroulement et les résultats attendus.
Aperçu :
INTRODUCTION
I. Contexte et Justification du projet
II. Objectifs du projet
III. Expression des besoins
IV. Étude financière du projet
V. Planification du projet
VI. Contraintes du projet
VII. Les Livrables
CONCLUSION

Introduction
Le cahier des charges est un document qui sert de contrat entre le maître d’œuvre et le
maitre d’ouvrage. C’est un document contenant des spécifications sur ce que le futur système
doit faire dans son environnement (ses buts), les principaux services qu’il doit rendre (besoins
fonctionnels), les exigences qualitatives souhaitées ainsi que les contraintes sous lesquelles il
doit être développé. Le développement d’une application d’adressage est un projet qui a pour
principal objectif l’amélioration du repérage et de l’orientation, Faciliter les interventions
d’urgence : ambulances, pompier, police et de localiser les services urbains. Le présent
chapitre décrit le contexte, les besoins fonctionnels, les besoins non fonctionnels et les objectifs
de notre projet, il a ainsi pour finalités de définir le projet de manière simple et détaillé.

I. CONTEXTE ET JUSTIFICATION DU PROJET
Les usagers des villes ayant connu et/ou connaissant une croissance urbaine forte et
rapide se retrouvent souvent confrontés à des difficultés de repérage et d’orientation. Une
absence d’adresse entraîne un lot de conséquences plus ou moins fâcheux, comme la difficulté,
voire l’impossibilité de recevoir du courrier à domicile, de recevoir des visiteurs, de se rendre
en taxi à une adresse précise, de recevoir des secours rapidement, … Les difficultés se situent
également au niveau des autorités locales qui se trouvent souvent dans l’incapacité de repérer
géographiquement une adresse. Les clients de CESD SA étant principalement du domaine du
e-commerce et de la finance, il est important pour une société de e-commerce par exemple de
connaitre l’adresse de ses clients afin de pouvoir mettre sur pied des services tel que la livraison
à domicile. Au Cameroun, l’adressage est communal, c’est-à-dire que l’adresse d’une
habitation dépend de la commune dans laquelle elle se trouve. Aujourd’hui dû à la complexité
et la lenteur du processus, nous avons quelques habitants de certains quartiers qui possède des
adresses aujourd’hui mais cela n’est pas vulgarisé.
C’est à l‘égard de tout cela que nous nous sommes proposés de moderniser et
d’automatiser le processus d’adressage afin de permettre à tout le monde de pouvoir demander
une adresse à partie un simple téléphone portable, outil que possède la plupart des camerounais
aujourd’hui. C’est dans cette ordre d’idée que nous avons pensée à Mettre Sur Pied Un
Système D’Adressage Numérique.
II. OBJECTIFS DU PROJET
Objectif général du projet
Il s’agit pour nous de permettre aux habitants de pouvoir obtenir une adresse pour leur
domicile ou leur bureau facilement.
Objectif spécifique
Pour les habitants :

➢ Faciliter le repérage et l’orientation, grâce à un système simple d’identification
valable pour tous les usagers.
➢ Faciliter les interventions d’urgence : ambulances, pompiers, police…
➢ En matière de services urbains divers : taxis, distribution du courrier et des
messages à domicile, …
➢ Et enfin, en matière de sentiment de citoyenneté et d’appropriation d’une ville.
Pour les autorités municipales, les administrations et les concessionnaires des réseaux,
l’adressage permettra :
➢ L’amélioration de la fiscalité locale

➢ La mise en place d'un suivi et d'une aide à la programmation urbaine en matière de
voirie, réseaux divers et équipements.
➢ L’établissement des listes électorales et la zone géographique des bureaux de votes
➢ La lutte contre les épidémies en “temps réel“
III. CIBLES
MyAddress est ouvert au grand public
IV. EXPRESSION DES BESOINS
L’expression des besoins est une étape dans un projet permettant de définir tout ce que
l’on souhaite en ressortant tout ce qui est obligatoire, fonctionnel et non fonctionnel. En outre,
dans cette partie, nous définirons précisément quelles sont les fonctions à remplir par notre
système ; qu’est-ce que notre système fera d’un point de vue fonctionnel et non fonctionnel.
Besoins fonctionnels
Il s’agit ici de capturer les actions qui devront être réalisées par le système en termes de
fonctionnalités capitale pour ce dernier.
En ce qui concerne notre système d’adressage de domicile, il devra permettre de couvrir

les points suivants regroupé en module.
➢ Module gestion de compte :

✓ Créer/modifier/supprimer des comptes utilisateur
✓ Authentifier un utilisateur (une seul fois, au premier lancement de
l’application)
➢ Module gestions des adresses :
✓ Demander une adresse
✓ Transférer une adresse
✓ Suivre une adresse (être capable de ressortir tes anciennes adresses)
✓ Certifier son adresse
➢ Module de navigation
✓ Naviguer vers une autre adresse
➢ Module d’utilisation d’adresse
✓ Partager son adresse avec un contact
✓ Résolution d’adresse
✓ Protéger son adresse (rendre public ou privée)
Besoins non fonctionnels
L’application devra répondre aux ;
➢ Exigences de qualité
✓ Ergonomie, efficacité, robustesse : la manipulation de l’application ne
devrait causer aucun problème à l’utilisateur et nous devons avoir de
belles interfaces ;
✓ Guide d’utilisateur : tout utilisateur de l’application doit pouvoir trouver
de l’aide s’il rencontre un problème ;
✓ Temps de latence : La génération d’adresse ne devra pas durer plus de 5
minutes
➢ Exigences de sécurité
✓ L’accès aux interfaces clés ne doit se faire qu’après authentification
✓ Tous les terminaux (mobiles) pour se connecter à l’application,
doivent être autorisées (préalablement enregistrées dans le système)

V. INTERVENANTS
NOMS Titre Rôle
MEKONTSO JULES AUFFRED Etudiant à l’IAI niveau 2 Chargé de l’execusion

du projet (analyste
programmeur)
M.MOMO ARNAUD Ingénieur informaticien et Encadrant

PDG de CESD professionnel
M.NDOUMI Ingénieur informaticien et Encadrant academique

Enseignant à l’IAI
VI. ETUDE FINANCIERE DU PROJET
Ressources humaines
NOMS Titre Rôle
MEKONTSO JULES AUFFRED Etudiant à l’IAI niveau 2 Chargé de l’exécution

du projet (analyste
programmeur)
M.MOMO ARNAUD Ingénieur informaticien et Encadrant

PDG de CESD professionnel
M.NDOUMI Ingénieur informaticien et Encadrant académique

Enseignant à l’IAI
Ressources matérielles
Matériel Caractéristiques Fabriquant

✓ Core i5 6300U 2.4GH
Pc portable ✓ 8Gb RAM Dell inc
✓ 250Gb
✓ 4G LTE DL
Modem ✓ ● WiFi standard: 802.11b / g / n Huawei

Ressources logicielles
Nom du logiciel Utilisation Taille Version Editeur
❖ Navigateur web 64 bits : Google Inc.

75.0.3578.9
Google chrome 75.1Mo 8 (Build
officiel)
Edraw max ❖ Outils de dessin de notre 0,99GO 9.0.0.0 Edraw soft

plan
Microsoft IIS 10.0.18 ❖ Serveur web 40 Mo 10.0.18 Microsoft
Visual Studio 2019 ❖ Environnement de 2,71 Go 2019 Microsoft

comminuty édition développement intégré
SUITE ADOBE CS6 ❖ Outil de retouche 15 Go CS6 ADOBE

d’images
Postman ❖ Outils de test api 74MO 7.6
GANTT PROJECT ❖ Outil d’aide à la 9 2.0.10 Free Software

planification des projets .22 Mo Fondation
SYSBASE POWER ❖ Outil de modélisation 258 Mo 15 SYSBASE

AMC
Microsoft SQL Server SGBD 3.9 Go 2019 Microsoft
Windows 10 ❖ Interface homme- 5 Go 10 Microsoft

machine
Microsoft office ❖ Edition des documents & 1,18 Go 365 Microsoft

rapports
QGIS ❖ Logiciel SIG 3.0.1 QGIS
Adobe XD ❖ Logiciel de prototypage 2go 35.3 Adobe Inc

Estimation du coût du projet
Tableau 5-estimation du coût du projet
Libellé Quantité P.U (en FCFA) Montant
❖ Matériels informatiques
Ordinateur portable 1 337 350 337 350
Imprimante HP Officejet 1 335 000 335 000

7313
Total 762 350
❖ Logiciels
Visual Studio 2013 1 Gratuit Gratuit
Community édition
GANTT PROJECT 1 Gratuit Gratuit
Google chrome 1 Gratuit Gratuit
Microsoft sql server 1 2 462 850 2462850
Office 365 1 546 250 546 250
Windows 10 1 138 000 138 000
Edraw max 1 236 145 236 145
Adobe Photoshop 1 370 000 370 000
Power AMC 1 1 562 175 1 562 175
Adobe XD 1 370 000 370 000
QGIS 1 Gratuit Gratuit
Total 5 685 420
❖ Rémunérations
Chef de projet 1 100 000/jour (Sur 120 jours) 12 000 000
Consultant 1 90 000/jour (Sur 30 jours) 2 700 000

TESTEUR 1 80 000/jour (Sur 15jours) 1 200 000
Développeur 1 50 000/jour (Sur 120jours) 6 000 000
Total 21 900 000 (Sur 4 mois)
❖ Divers
Format, règles, stylo / / 15 000
Accès à internet 24h/24 10 000/30 jours (sur 4 mois) 40 000
Total 55 000
❖ Risques du projet
Forfait (20% du coût Coût total du projet sans risque : Total Forfait :
total)
35 263 924Fcfa 7 052 784Fcfa
Montant Final du projet 42 316 708Fcfa
VII. PLANIFICATION DU PROJET
Déroulement
Le diagramme de Gantt est un outil qui permet sur un même plan de faire apparaître les
tâches d’un projet leur ordonnancement et dépendance ainsi que le suivi de l’avancement et les
ressources affectées.
Planification des taches

Tableau 6-planification des tâches
Tache Durée (en jour)
Insertion 14
Cahier des charges 5
Analyse 25

Conception 16
Réalisation 26
Tests & maintenance 5
Déploiement 1
Guide d’utilisation 1
Rédaction du rapport 100
Exploitation Indéterminée
Maintenance Indéterminée
Diagramme de Gantt
Figure 4-Diagramme de gantt du projet

VIII. CONTRAINTES
Pour réaliser notre application nous devrons respecter 3 contraintes à savoir :
➢ Les contraintes sur coût : Le budget fixé pour la réalisation de l’application devra
être respecté conformément aux prévisions c’est-à-dire sans surenchère ou sous-
enchère ;
➢ Les contraintes sur le délai : La réalisation de ce système devra respecter les
contraintes de temps fixés et donc être faite sur une durée de deux (02) mois et
devra respecter les objectifs fixés ;
➢ Les contraintes de qualités : Après le prix et un délai fixer, nous devons produire
une application flexible et réutilisable et surtout évolutive.
IX. LIVRABLES
A la fin de ce projet nous livrerons :
➢ Le rapport complet
✓ Phase d’insertion scindée en 3 parties : la première partie qui renseigne
sur l’accueil et l’intégration dans l’établissement, la deuxième partie sur
la présentation de l’établissement et enfin la troisième partie sur la
présentation du thème.
✓ Phase technique comprenant 5 dossiers à savoir : le cahier des charges,
le dossier d’analyse, le dossier de conception, le dossier de réalisation,
le dossier du guide d’utilisateur et guide d’utilisation ;
➢ Un CD-ROM comprenant
✓ Le code source ;
✓ Le manuel d’utilisation.
➢ Une application mobile iOS/Android opérationnelle en ligne.

Conclusion
Parvenue au terme de cette partie où il a été question pour nous de fixer les bases de la
relation contractuelle entre le maître d’ouvrage et la maîtrise d‘œuvre. Nous avons ainsi fixé
les objectifs visés par la conception de ce système et dressé une liste des besoins fonctionnels
et non fonctionnels de ce dernier. Nous y avons également établi une étude financière du projet
qui fait appel à la présentation des ressources humaines, matériels et logiciels nécessaires, ainsi
qu’à une planification du projet sur une durée de quatre (04) mois dans le respect des contraintes
de coût et de qualités du logiciel. Ce document fera pour nous office de cahier de charge et nous
permettra de passer à la prochaine étape de réalisation de notre application qu’ai la phase
d’Analyse.

DOSSIER II. ANALYSE
RÉSUMÉ
La phase d’analyse est une étape primordiale dans la bonne marche d’un projet. Elle
présente de façon claire l’étude de l’existant, ses limites, les solutions proposées, le choix de la
méthode d’analyse et enfin la modélisation de la solution future.
Aperçu
I. Description de l’existant
II. Présentation des limites de l’existant
III. Problématique
IV. Présentation de la solution proposée
V. Présentation de la méthodologie d’analyse
VI. Modélisation de la solution

Introduction
L’analyse est la décomposition d’un problème en ses différents éléments en vue d’un
traitement informatique. De ce fait pour la bonne réalisation d’un projet, il est très important
d’effectuer une bonne analyse afin d’atteindre les objectifs spécifiés dans le cahier des charges.
La réalisation d’un bon projet repose principalement sur son analyse. Ainsi, un projet mal
analysé ne saurait donner de bons résultats. Cette partie sera essentiellement consacrée à
l’analyse minutieuse des problèmes rencontrés avec l’utilisation des logiciels de gestion
commerciale exotique

I. DESCRIPTION DE L’EXISTANT
L’adressage au Cameroun
L’adressage des villes du Cameroun se fait en plusieurs étape, tout d’abord on identifie
les voies (rues, avenu, routes etc…), puis on numérote en fonction du système de numérotation
choisi. Le système de numérotation adopté par les villes du Cameroun consacre les nombres
pairs à droite et impairs à gauche, correspondant à la distance séparant l’entrée de la
construction au début de la rue. Nous avons donc un numéro représentant la distance en mètre
qui sépare l’habitation de l’entrée de la rue, un nom de rue un nom de quartier et le nom de la
commune ; c’est ainsi que nous avons une adresse avec suffisamment d’information pour
localiser de manière exacte l’emplacement. Au-delà d’être une opération qui vise à faciliter le
repérage, l’adressage constitue une initiative qui entend améliorer la gestion urbaine.
Etude des systèmes de numérotation existants
a. Le Système continu
Les immeubles sont numérotés avec des numéros croissants depuis le début de la voie.
Le long de cette voie, les numéros pairs sont à droite (2, 4, 6, etc), les numéros impairs sont à
gauche. Cette numérotation convient aux zones urbanisées dense (centre-ville).
Figure 5-système de numérotation continu

b. Le système métrique
Les numéros attribués aux propriétés représentent la distance en mètres séparant le début
de la voie et l'entrée de l'habitation. Cette numérotation permet d'intercaler de nouveaux
numéros sans modifier la numérotation existante et sans risque de créer des numéros bis ou ter.
Le long de la voie, les numéros pairs sont à droite (2, 4, 6, etc.), les numéros impairs sont à
gauche. La numérotation métrique est particulièrement efficace pour les organismes de secours
puisque le numéro comporte la distance à parcourir depuis le début de la voie.
Figure 6-système de numérotation métrique
II. CRITIQUE DE L’EXISTANT
Après une étude minutieuse menée sur le système d’adressage des villes du Cameroun
dans la partie précédente, nous aborderons à présent les insuffisances de ce dernier ainsi que
pour les systèmes de numérotation déjà existants tout en ressortant les impacts négatifs sur
l’attribution des adresses aux domiciles. Le tableau suivant illustre la critique de l’existant.
Tableau 7-critique de l'existant
Système de numérotation Limite Conséquence
Système continu Problème d’évolution, L’ajout nécessaire de « Bis », «

d’adressage d’un nouveau Ter » etc.
domiciles construit entre
d’autre déjà existants
Système métrique Presque inexistante Presque inexistante

III. PROBLEMATIQUE
L’expansion spatiale et la croissance démographique ne cesse d’impressionner. Cette

urbanisation rapide et mal contrôlée aggrave les difficultés d’orientation et de localisation. Les
populations recourent à des noms usuels de lieux même là où les rues sont dénommées.
Lorsqu’on entend un piéton héler un taxi, « Poste centrale » ; « Rue des Banques » ; « Carrefour
Mvog Mbi » ou encore « Rue Dragages ». Pourtant les noms de baptême de ces lieux sont :
Place Ahmadou Ahidjo ; Avenue Charles de Gaulles ; Place Awae et Rue Charles Bindzi. Le
processus d’adressage aujourd’hui n’es pas à la portée de tous, le citoyen doit se rendre au
comité d’adressage de sa commune pour faire une demande d’adresse. Le processus est
complexe et long raison pour laquelle aujourd’hui nous avons uniquement quelques habitations
de certains quartiers qui possède une adresse. Ceci remet en cause le système d’adressage
utilisés qui jusqu’ici se fait manuellement. Nous nous interrogeons sur comment améliorer le
système d’adressage tel qu’existant ?
IV. PRESENTATION DE LA SOLUTION PROPOSE
L’étude de l’existant est l’une des étapes indispensables à la mise en place d’une solution
répondant de manière efficiente aux exigences de l’entreprise et adaptée à l’ère technologique
courante. Jusqu’ici, L’étude du système de numérotation des villes du Cameroun ainsi que des
autres systèmes existants nous a permis non seulement de mieux cerner le problème qu’est
l’adressage au Cameroun en définissant les objectifs à atteindre en termes de d’efficacité, de
fiabilité, et de fonctionnement mais aussi de prendre connaissance des systèmes actuels en
dégagent leurs limites. Par suite de cette analyse, nous constatons que seul le système de
numérotation métrique peut répondre efficacement au besoin d’adressage des villes du
Cameroun. C’est pourquoi nous couplerons donc à ce type de numérotation un programme
informatique permettant de générer de manière automatique les adresses afin de permettre à
n’importe quel camerounais de pouvoir demander une adresse et de favoriser le repérage autant
pour les habitants que pour les visiteurs car le code de l’adresse indique immédiatement dans
quelle zone se trouve la rue, la construction. Au-delà d’être une opération qui vise à faciliter le
repérage, ce système d’adressage constitue une initiative qui entend améliorer la gestion
urbaine.

V. PRÉSENTATION DE LA DÉMARCHE D’ANALYSE
L’analyse est une étape fondamentale dans la conception d’un logiciel. C’est la base de
tous travaux de réalisation de systèmes d’information. Un système d’information est un
ensemble de ressources matérielles ou immatérielles ayant pour but de générer les données,
collecter, stocker, traiter et diffuser les informations parfois grâce aux TIC. Plusieurs méthodes
et langages ont étés développés pour faciliter et normaliser l’analyse et la conception des
systèmes d’information parmi lesquels nous avons principalement UML et MERISE.
MERISE est une méthode d’analyse, de conception structurelle et de réalisation des

systèmes d’informations très utilisées notamment dans les entreprises françaises. Elle est basée
sur la séparation des données et des traitements à effectuer en plusieurs modèles conceptuels et
physiques. Son but principal est d’arriver à concevoir un système d’information (SI). C’est une
méthode systémique d’analyse et de conception de SI qui propose de considérer le système réel
selon deux points de vue : une vue statique (données) et une vue dynamique (traitements).
UML quant à lui, est un langage de modélisation des systèmes standard, qui utilise des
diagrammes pour présenter chaque aspect d’un système en s’appuyant sur la notion d’orientée
objet qui est un véritable atout pour ce langage. UML propose donc une approche différente de
celle de MERISE en ce sens qu’il associe les données aux traitements. En effet, avec UML
centraliser les données d’un type et les traitements associés permet de limiter les points de
maintenance dans le code et faciliter l’accès à l’information en cas d’évolution du logiciel. De
plus, UML décrit la dynamique du système d’information comme un ensemble d’opérations
attachées aux objets du système.
Etude comparative entre UML et MERISE

Tableau 8-etude comparative entre UML et Merise
MERISE UML
Méthode d’Étude et de Réalisation Unified Modeling Language

Informatique pour les Systèmes d’Entreprises
MERISE est une méthode systémique UML est un langage de modélisation objet à qui
d’analyse et de conception de systèmes il faut associer un processus (2TUP, RUP, XUP) pour
d’information. C'est-à-dire qu’elle utilise une en faire une méthode
approche systémique.

MERISE `propose de considérer le UML propose une approche différente en ce

système réel selon deux points de vue : sens qu’il associe les données et les traitements
• Une vue statique (données) Avec UML, centraliser les données d’un type et
les traitements associés permet de limiter les points de
• Une vue dynamique (traitements) maintenance dans le code et facilite l’accès à
l’information en cas d’évolution
Avec la méthode MERISE, nous avons
une étude séparée des données et des
traitements
Approche systémique Approche objet
Démarche « Bottom Up » : De la base de Démarche « Top Down » : Du modèle vers la

données vers le code base de données
Justification de la méthode choisie
Au regard de la complexité croissante des systèmes d’informations et de cette analyse

comparative, UML s’avère être la meilleure démarche d’analyse pour ce projet. UML est un
langage unifié de modélisation qui permet de spécifier, visualiser, construire et documenter de
manière claire et précise un système d’information. Le modèle fourni par UML est valable pour
n'importe quel langage de programmation et grâce à ses diagrammes, il offre une description
statique, dynamique et fonctionnelle du système à réaliser.
Présentation du langage UML
a. Historique
Lorsque la programmation à objets prend de l’importance dans les années 1990, la

nécessité d’une méthode qui lui soit adapté devient évidente. Plus de cinquante méthodes vue
le jour. En 1994 le consensus se fait autour de trois méthodes : OMT (Object Modeling
Technique) de James Rumbaugh, OOD (Object Oriented Design) ou Booch de Grady Booch et
OOSE (Object Oriented Software Engineering) d’Ivar Jacobson. En 1995 James Rumbaugh et
Grady Booch se mirent d’accord pour construire une méthode unifiée Unified Method 0.8 ; En
1996 Ivar Jacobson leurs rejoint pour construire UML 0.9. De nombreux acteurs du monde du
génie s’associent à cette effort et UML 1.0 est soumis à OMG (Object Management Group). Et
c’est en novembre 1997 que OMG adopte UML 1.1 comme langage de modélisation à objet.

Actuellement à sa version 2.5 bêta depuis septembre 2013 ; Nous utiliserons sa version 1.4 dans
la suite de notre travail.
b. Description
UML 1.4 se définit comme un langage de modélisation graphique et textuel destiné à

comprendre et décrire les besoins, spécifier et documenter les systèmes, esquisser des
architectures logicielles, concevoir des solutions et communiquer des points de vue. UML
unifie à la fois les notions et les concepts orientés objets. Il ne s’agit pas d’une simple notation
graphique car les concepts transmis par un diagramme ont une sémantique précise et sont
porteurs de sens au même titre que les mots d’un langage. C’est un langage standard de
modélisation des systèmes d’information à objet. UML 1.4 qui compte neuf (09) diagrammes,
et une subdivision du système en deux (02) grandes vues :
➢ La vue statique qui représente le système physiquement et comporte cinq (05)

diagrammes :
✓ Diagramme de classe ;
✓ Diagramme d’objet ;
✓ Diagramme de cas d’utilisation ;
✓ Diagramme de composants ;
✓ Diagramme de déploiement.
➢ La vue dynamique qui représente les interactions effectuées dans le système et
le fonctionnement dynamique des différents acteurs du système. Elle compte
quatre (04) diagrammes :
✓ Diagramme d’activité ;
✓ Diagramme de séquence ;
✓ Diagramme d’état transition ;
✓ Diagramme de collaboration.
UML étant un langage formel et normalisé, il est un bon support de communication

dans l’élaboration d’une solution informatique, sa polyvalence et sa souplesse font de lui un
langage universel. Pour développer des solutions, on a besoin de lui associer une méthode
générique qui s’attache à ses diagrammes, il en existe plusieurs méthodes : 2TUP, R-UP, X-
UP, UP, AUP, AM, etc. Notre choix repose sur la méthode 2TUP ;

Présentation du processus choisi
La conception d’un système d’information passe par une séquence d’étapes ordonnées
dont l’objectif est de produire un logiciel répondant aux besoins des utilisateurs dans le temps
et des coûts prévisibles. Or UML est un langage qui ne propose que des diagrammes. Pour
concevoir un SI avec lui, il est impératif de lui associer un processus. Dans le tableau qui suit
nous avons répertorier les processus existants :
Tableau 9-les processus UML
Processus Description
2TUP 2TUP est un processus unifié qui a pour but d’apporter une
réponse aux contraintes de changement fonctionnelles et technique qui
s’imposent aux systèmes d’information, il propose un cycle de
développement qui dissocie les aspects techniques des aspects
fonctionnels
RUP Dérivé d’UP et commercialisé par IBM en 1998, RUP est l’une
des plus célèbres implémentations de la méthode UP permettant de
donner un cadre au développement logiciel. RUP est un exemple de
formalisation d’un processus fondé sur le cycle de vie en spirale
Présentation du processus unifié 2TUP
Un processus définit une séquence d'étapes ordonnées qui permet de produire un

système logiciel ou de faire évoluer un système existant. Un processus est décomposé suivant
l'axe de développement technique et l'axe de gestion du développement. L'axe de
développement technique se préoccupe de la production tandis que la gestion du développement
mesure, puis prévoit les coûts et les délais. La diversité des systèmes et des techniques de
modélisation ne permet pas de définir un seul processus universel. Les créateurs d'UML ont
travaillé à unifier les meilleures pratiques de développement orienté objet pour donner le
processus unifié. Le processus unifié (UP : Unified Process) est un processus de développement
logiciel mené par UML. Le processus unifié est :

➢ Itératif et incrémental : le projet est découpé en des itérations de courte

durée. Ces itérations aident à mieux suivre l'avancement du système global. A chaque
itération, il est produit un exécutable de façon incrémentale.
➢ Piloté par les risques : il est identifié et écarté au plut tôt tout risque
pouvant conduire à un échec du projet.
➢ Centré sur l'architecture : le système est décomposé en modules pour des

besoins de maintenabilité et d'évolutivité.
➢ Conduit par les cas d'utilisation : le processus met en avant les besoins et
exigences des futurs utilisateurs du système.
La figure ci-dessous nous présente le processus 2TUP :
Figure 7-le processus 2TUP
2TUP est un processus unifié qui a pour but d'apporter une réponse aux contraintes de
changement fonctionnelles et techniques qui s'imposent aux systèmes d'information. 2TUP
propose un cycle de développement qui dissocie les aspects techniques des aspects fonctionnels.
Il part du constat que toute évolution imposée au système d'information peut se décomposer et
se traiter parallèlement, suivant un axe fonctionnel et un axe technique. Il distingue ainsi deux

branches (fonctionnelle et technique) dont les résultats sont fusionnés pour réaliser le système.
On obtient un processus de développement en Y comme l'illustre la figure ci-dessous. Il faut
noter que le processus 2TUP commence d'abord par une étude préliminaire. Dans cette étude
préliminaire, il s'agit d'identifier les acteurs qui vont interagir avec le système, les messages
qu'échangent les acteurs et le système, puis à produire un cahier de charges et enfin à modéliser
le contexte.
VI. MODÉLISATION DE LA SOLUTION
Diagramme de cas d’utilisation
Un diagramme de cas d’utilisation est un diagramme UML qui présente les acteurs, les
fonctionnalités du futur système à développer et les différentes relations entre ces derniers. Bien
souvent, la maitrise d’ouvrage et les utilisateurs ne sont pas les informaticiens ; il leur faut donc
un moyen simple d’exprimer leurs besoins. C’est précisément le rôle du diagramme de cas
d’utilisation qui permet de recueillir, d’analyser et d’organiser les besoins afin de pouvoir
recenser les différents modules du système.
c. Éléments constitutifs du diagramme de cas

d’utilisation
Les éléments qui interviennent dans un diagramme de cas d’utilisation sont les suivant :
Tableau 10-Éléments du diagramme de cas d'utilisation
Eléments du diagramme Description
Les acteurs sont des objets (personnes ou autre système)

qui vont exploiter le système. Ces derniers peuvent êtres Humains,
logiciel, des automates ou autres systèmes ;
Ils interagissent avec le système, sont externe au système

et jouent un rôle important dans le système
Un cas d’utilisation est une description du dialogue entre

un acteur et le système, c’est également une description de haut
niveau de la façon dont le système sera utilisé.
Relation de généralisation permettant de représenter les

sous cas d’un cas d’utilisation global ou entre acteur ;

Relation d’extension entre cas d’utilisation ne nécessitant

pas une obligation
Relation d’inclusion entre cas d’utilisation. Elle nécessite

une obligation
d. Formalisme du diagramme de cas d’utilisation
Le formalisme d‘un diagramme de cas d’utilisation est le suivant :
Figure 8-formalisme d'un diagramme de cas d'utilisation
e. Identification Des Acteurs Et Des Cas D’Utilisations
Plusieurs acteurs entrent en jeu dans notre système, ils sont répertoriés dans le tableau
suivant :
Tableau 11-les acteurs et cas d'utilisation du système
Cas d’utilisation Acteurs Intention
S’authentifier Utilisateur S’authentifier afin de pouvoir

demander une adresse
Demander une adresse Utilisateur Permettre à l’application de le

localiser et de générer une
adresse

Naviguer vers une adresse Utilisateur Utiliser la navigation pour

s’orienter et se deplacer
Partager son adresse Utilisateur Envoyer son adresse à ses amis
Rechercher une adresse Utilisateur Taper un numéro de portable et

optenir son adresse
Transférer une adresse Utilisateur Donner son adresse à un autre

utilisateur en cas de
déménagement
Certifier son adresse Administrateur Faire de son adresse une adresse

approuvé et utilisable par des
banques et légalement
Gérer son profil Utilisateur Modifier son profil (mot de

passe, email)
Enregistrer un terrain Utilisateur Parcourir les bornes de son

terrain et l’enregistrer sur la
carte
Vérifier un terrain Utilisateur Vérifier si un terrain est titré ou

pas
Protéger son adresse Utilisateur Changer le niveau de visibilité

de son adresse, décider si son
adresse est visible par d’autres
ou pas

f. Représentation du diagramme de cas d’utilisation

utilisateur
<<extend>>
s'inscrire
<<include>>
modifier supprimer
gérer son compte

<<include>>
s'authentifier
<<include>>
<<include>>
enregistrer un terrain
Utilisateur
verifier un terrain
protéger son adresse

<<include>>
partager son adresse

<<include>>
naviguer vers une adresse <<include>>
<<include>>
transférer son adresse
résoudre une adresse
<<include>>
Figure 9-Représentation du diagramme de cas d’utilisation utilisateur

g. Représentation du diagramme de cas d’utilisation

globale
<< include >>
certifier une adresse
modifier localiser utilisateur
<< include >>
Administrateur suivre une adresse <<include>>

supprimer
gérer son compte
<< include >> <<include>>

<< include >> générer une adresse
s'authentifier
<< extend >>

système
s'inscrire
<< include >>

<<include>>
<< include >>
résoudre une adresse
Utilisateur
naviguer vers une

<< include >>
adresse
calculer le plus cour chemin
<< include >>

partager son adresse
<< include >>

transférer son adresse
<< include >>

protéger son adresse
<<include>>
enregistrer un terrain
verifier un terrain <<include>>
Figure 10-Représentation du diagramme de cas d’utilisation globale
h. Description textuelle des cas d’utilisation
Chaque cas d'utilisation, est associé à une série d'actions représentant la fonctionnalité
voulue, ainsi que les stratégies à utiliser dans l'alternative où la validation échoue, ou des erreurs
se produisent.
Un cas d’utilisation est donc une abstraction de plusieurs chemins d’exécution. Une
instance de cas d’utilisation est appelée : « scénario ». C’est un chemin particulier pris lors de
l’exécution d’un cas d’utilisation. Le nombre d’instances pour un cas d’utilisation peut être très
important, voire infini. La description d’un cas d’utilisation se fait par des scenarii qui
définissent la suite logique des interactions qui constitue ce cas. Cette description se fait de
manière simple, par un texte compréhensible par les personnes du domaine de l’application.
Elle précise également ce que fait l’acteur et ce que fait le système.

Les scénarios (scénarii) peuvent être classés en :
➢ Scénario principal ou nominal : Il correspond à l’instance principale du cas

d’utilisation. C’est le scénario typique de succès ;
➢ Scénarios secondaires : Il peut être un cas alternatif (un choix), un cas
exceptionnel ou une erreur.
La description textuelle est constituée des éléments suivants :
➢ Le présupposé : Ce sont les actions qui doivent être remplies avant le lancement
du cas d’utilisation ;
➢ La précondition : C’est l’ensemble des conditions qui doivent être remplies
avant le lancement du cas d’utilisation ;
➢ Le déclencheur : C’est l’élément qui déclenche le cas d’utilisation ;
➢ Le dialogue : C’est le scénario principal et le Scénario secondaire ;
➢ La post condition : Ce sont les différents mécanismes pouvant conduire à la fin
de l’exécution du cas d’utilisation ;
➢ L’arrêt : C’est l’état du système à l’arrêt du cas d’utilisation.
Description textuelle de quelque cas d’utilisation :
➢ S’authentifier
Tableau 12-description textuelle du cas d'utilisation s'authentifier
Sommaire d’identification
Titre : Authentification
But : avoir accès aux fonctionnalités du système
Résumé : permettre à l’utilisateur de l’application de s’authentifier avec ses
identifiants (numéro de téléphone et mot de passe)
Acteur(s) concerné(s) : utilisateur
Description des enchaînements
Présupposé : Le système est déployé et fonctionnel
Précondition : l’utilisateur doit être inscrit
Déclencheur : lancer l’application
Dialogue :
• Scénario principal :
1) L’interface de connexion s’affiche ;
2) L’utilisateur renseigne son numéro et son mot de passe et lance la connexion ;
3) Le système vérifie ses informations et lance la page d’accueil si l’utilisateur
existe ;
• Scénario alternatif :
- A5) les informations ne sont pas correctes, on retourne à 2) ;

• Postcondition succès : L’application affiche l’accueil de l’application ;

• Postcondition échec : l’opération n’aboutit pas, le formulaire de connexion est
réaffiché à l’utilisateur
• Arrêt : affiche accueil de l’application
➢ Demander une adresse
Tableau 13-description textuelle du cas d'utilisation demande d'adresse
Demande d’adresse
Titre : demander une adresse
But : obtenir une adresse pour sa position
Résumé : permettre à l’utilisateur d’avoir une adresse pour son domicile, son bureau
ou son entreprise
Précondition : l’utilisateur doit être connecté
Déclencheur : appuyer sur demander une adresse
Dialogue :
4) Un pop-up s’affiche ;
5) L’utilisateur renseigne les informations demandées ;
6) Le système localise l’utilisateur ;
7) Le système utilise l’algorithme et génère une adresse en fonction des
coordonnées GPS récupérée
- A1) le système ne réussit pas à localiser l’utilisateur, l’opération est annulée et on
retourne à l’accueil ;
- A2) l’adresse généré existe déjà pour l’utilisateur, l’opération est annulée
• Postcondition succès : Le système affiche une nouvelle adresse générée ;
• Postcondition échec : l’opération n’aboutit pas, l’utilisateur est renvoyé à l’accueil
avec un message d’erreur
• Arrêt : affiche accueil de l’application avec nouvelle adresse
➢ Recherche d’adresse
Tableau 14-description textuelle cas d'utilisation rechercher une adresse
Recherche d’adresse
Titre : recherche d’adresse
But : connaitre une adresse à partir d’un numéro de téléphone
Résumé : permettre à l’utilisateur de pouvoir saisir un contact ou choisir parmi ses
contacts et obtenir son adresse

Précondition : l’utilisateur doit être connecté
Déclencheur : appuyer sur rechercher une adresse
Dialogue :
8) L’interface de recherche s’affiche avec les contacts et une barre de recherche
;
9) L’utilisateur choisi ou saisi un contact ;
10) Le système recherche dans la base de données l’adresse ;
11) Le système affiche l’adresse si elle existe et est public
- A1) le système ne trouve pas de correspondance et affiche 0 résultat ;
- A2) le système n’affiche pas d’adresse car elle est privée
• Postcondition succès : Le système affiche l’adresse du contact recherché ;
• Postcondition échec : l’opération n’aboutit pas, un message d’erreur est affiché à
l’utilisateur
• Arrêt : l’adresse est affichée
Diagramme de séquence
a. Présentation du diagramme de séquence
Les diagrammes des séquences documentent les interactions à mettre en œuvre entre les
classes pour réaliser un résultat, tel qu’un cas d’utilisation. UML étant conçu pour la
programmation orientée objet, ces communications entre les classes sont reconnues comme des
messages. Le diagramme des séquences énumère des objets horizontalement, et le temps
verticalement. Il modélise l’exécution des différents messages en fonction du temps
b. Eléments constitutifs du diagramme de séquence

Tableau 15-Eléments constitutif du diagramme de séquence
SYMBOLE SIGNIFICATION
OBJET
Les objets sont des instances des classes, et sont rangés

horizontalement. La représentation graphique pour un objet est
similaire à une classe (un rectangle) précédée du nom d'objet
(facultatif) et des deux points (:).

ACTEUR
Les acteurs peuvent également communiquer avec des objets,

ainsi ils peuvent eux aussi être énumérés en colonne. Un acteur
est modélisé en utilisant le symbole habituel.
LIGNE DE VIE
Les lignes de vie, Life Line, identifient l'existence de l'objet par

rapport au temps. La notation utilisée pour une ligne de vie est
une ligne pointillée verticale partant de l'objet.
ACTIVATEUR
Les activations, sont modélisées par des boîtes rectangulaires sur

la ligne de vie. Elles indiquent quand l'objet effectue une action.
MESSAGE
Les messages, modélisés par des flèches horizontales entre les

activations, indiquent les communications entre les objets.
Dans le diagramme de séquence on retrouve aussi des blocs les principaux sont :
✓ Le bloc Reference : qui permet de matérialiser la référence vers un cas d’utilisation ; il

est utilisé pour marquer l’appel d’un cas d’utilisation dans un autre (c’est une inclusion)
; Il représenté comme suit :
✓ Le bloc Alternative : qui permet de matérialiser les structures conditionnelles ; Il est

représenté comme suit :
✓ Le bloc Loop : qui permet de matérialiser une boucle ; Il est représenté comme suit :

✓ le bloc Option : qui permet de matérialiser les cas d’utilisation optionnels (c’est une
extension) ; Il est représenté comme suit :
c. Formalisme du diagramme de séquence
Figure 12-formalise
11-formalismedudiagramme
diagrammededesequence
sequence

d. Représentation des diagrammes de séquence
➢ Cas d’utilisation s’authentifier

authenti fi cati on
:systeme :sgbd
uti l i sateur
demarre l 'appl i cati on()
affi cher l a page l ogi n()
sai si l ogi n et mot de passe()
veri fi cati on des entrees()
al t champs vi de
noti fi cati on champs vi de()
val i de noti fi cati on
renvoi e page de l ogi n()
champs non vi de
envoi requete()
reponse requete()
al t uti l i sateur exi ste
affi che page d'accuei l ()
uti l i sateur exi ste pas
noti fi er uti l i dateur i nconnu()
val i de noti fi cati on()
revoi formul ai re d'i nscri pti on
Figure 13-diagramme de séquence s'authentifier

➢ Cas d’utilisation demander une adresse
demandeAdresse
:systeme :sgbd
utilisateur
ref
authentification()
clic sur ajouter une adresse()
generation d'adresse()
alt generation reussi

affiche adrersse()
echec de generation
affiche erreur
Figure 14-diagramme de séquence demander une adresse

➢ Cas d’utilisation rechercher une adresse
dns
:systeme :sgbd
uti l i sateur
ref
authenti fi cati on()
cl i c sur l e bouton resoudre une adresse()
affi che l 'acti vi te resoudre adresse()
sai si contact et val i de()

i ntegroger l a base de donnees()
recherche correspondance()
envoi repnse()
al t aucun resul tat
affi che aucun resul tat()
adresse pri vee

permi ssi on non accorde()
adresse trouve
affi cher adresse()
al t cl i c sur navi guer
redi ri ge vers acti vi te navi gati on()
cl i c sur partager
pop up de partage()
Figure 15-diagramme de séquence rechercher une adresse

➢ Cas d’utilisation inscription
inscription
:systeme :sgbd
utilisateur
demarre l'application()
affiche l'activite de login
s'inscrire()
affiche activite inscription()
saisi information()
verification des champs()
alt ok requete d'enregistrement()
reponse()
notification succes()
valide notification()
renvoie a l'activite login()
non ok notification erreur
valide notification
renvoie formulaire d'inscription
Figure 16-diagramme de séquence s'inscrire

➢ Cas d’utilisation naviguer vers une adresse
navi gati on
:systeme :sgbd
uti l i sateur
ref
authenti fi cati on()
cl i c sur navi gati on()
affi che acti vi te navi gati on()
sai si adresse()
veri fi cati on()
al t champ non vi de
veri fi e si adresse axi ste()
reponse()
al t adresse trouve()
l ace l a navi gati on()
pas de correspondance()
affi che erreur()
champ vi de
affi cher erreur()
Figure 17-diagramme de séquence ces d'utilisation naviguer vers une adresse
Diagramme d’activité
a. Présentation du diagramme de classe
Les diagrammes d’activités sont les diagrammes UML utilisés pour documenter le
déroulement des opérations dans un système. L’usage général des diagrammes d’activités
permet de faire apparaitre des flots de traitement induits par des processus internes par rapport
aux évènements externes.

b. Eléments constitutif du diagramme d’activité
Les éléments intervenant dans la représentation d’un diagramme d’activité sont recensés
dans le tableau suivant :
Tableau 16-elements constitutif du diagramme d'activité
Éléments Description
Nœud initiale, représentant le début de l’activité
Activite_1 Activité, correspond à un certain nombre d’action que

le système devra exécuter en réponse au besoin d’un
acteur
Flux, passage d’une activité a une autre
Synchronisation : type de flux ayant 2 entré et une

seule sorti ou une entré avec 2 sorti
Decision_4
Décision : représentant un choix alternatif
Nœud de fin d’activité
c. Formalisme du diagramme d’activité

UniteOrganisation_1 UniteOrganisation_2 UniteOrganisation_3
Activite_1
Activite_2 Activite_3
Decision_1
Figure 18-formalisme du diagramme d'activité

d. Représentation du diagramme d’activité
➢ Diagramme d’activité cas d’utilisation authentification
utilisateur systeme sgbd
demande de connection
affiche formulaire de login
saisi information
verification
[si oui]
[sinon] recherche profile
champs vide
[si non]
profil existant
[si oui]
affiche accueil

➢ Cas d’utilisation demande d’adresse
utilisateur systeme sgbd
affiche formulaire de login

demande de connection
[si non]
verificati
on
saisi information
[si oui] [si non]

champs vide
recherche profile
[si non]
profil existant
[si oui]
affiche accueil
clic sur ajouter adresse
generer adresse
[si non]
[si oui]
affiche reussit affiche erreur
adresse
complétion des information

de l'adresse
envoi a la bd
enregistre adresse
afficher adrese
Figure 19-diagramme d'activité, cas d'utilisation demande d'adresse

Conclusion
L’analyse de l’automatisation du système d’adressage nous a permis de parcourir
plusieurs notions afin de produire une analyse qui répond aux exigences prérequis. Ainsi nous
avons de prime-abord d’écrire l’existant, donner les limites de cet existant pour ensuite proposer
une solution ; ensuite parler de la méthodologie à utiliser , enfin étudier avec détail la solution
proposée en modélisant nos différents diagrammes grâce au logiciel Power AMC 15.1 ;il en
ressort que dans ce dossier les éléments pris en compte nous ont permis de matérialiser les
besoins fonctionnels ; ces derniers nous seront d’une importance capitale dans l’expression des
besoins techniques. Le dossier d’analyse à travers les différentes activités réalisées, nous a
offert des outils qui nous permettront d’amorcer de façon plus aisée le dossier de conception.

DOSSIER III. CONCEPTION
RÉSUMÉ
Le dossier de conception permet de modéliser dans son ensemble la solution proposée

et de recueillir les informations nécessaires à la mise en place de la base de données complexe
et efficace. De ce fait, il prévoit le système futur.
Aperçu
Introduction
I. Capture des besoins techniques
II. Conception générique
Conclusion

Introduction
La réalisation d’un dossier d’analyse est très importante pour l’avancement de
l’application, elle garantit la fiabilité de maintenance et d’utilisation d’un logiciel. Cela dit,
après avoir analysé notre système, nous allons passer à la conception de notre futur système.
Pour le faire nous suivrons les étapes de la branche de réalisation de la méthode 2TUP, en
réalisant les diagrammes associés à ces étapes à savoir le diagramme de classe et le diagramme
d’état transition.

I. CAPTURE DES BESOINS TECHNIQUE
Architecture physique de l’application
L’architecture d’un logiciel est la fondation d’un système. Car une bonne
architecture dépend entièrement du fait qu’un système soit évolutif, extensible et
maintenable.
a. Comparaisons des architectures
Il est question pour nous ici de présenter à travers un tableau une comparaison des
architectures ce qui nous permettras de mieux orienter notre choix
Tableau 17-comparaisons des architectures physiques
Point de 2 tiers 3 tiers Micro services

comparaison
Complexe (la couche Moins complexe
Administration application est (Les applications Facile car les services
du système physiquement répartie peuvent être gérées sont indépendants
centralement sur le
Sur plusieurs postes serveur)
clients)
Faible Moyenne
Sécurité (Sécurité au niveau des (Raffinée au niveau Elevé (sécurité au
données) des services ou des niveau de l’accès aux
méthodes) données, l’utilisateur
ne manipule pas
directement les
données)
Encapsulation Faible Elevée Elevée
(Les tables de données (Le client fait appel à
Des données sont directement des services ou (Le client fait appel à
Accessibles) méthodes) des micro services
indépendants)
Performance Faible Bonne Optimale
(Plusieurs requêtes SQL (Seulement les appels (Seulement les appels
sont transmises sur le de services et les de services et les
Réseaux, les données réponses sont réponses sont
sélectionnées doivent Mis sur le réseau) Mis sur le réseau)
être
Acheminées vers le client
pour analyse)
Extensibilité Faible Excellente Excellente
(Gestion limitée des liens (Possibilité de répartir (Possibilité de répartir
réseaux avec le client) dynamiquement la dynamiquement la

charge sur plusieurs charge sur plusieurs
serveurs) serveurs)
Réutilisation Faible Excellente Excellente
(Application (Réutilisation des (Réutilisation des
monolithique sur le services et des objets) micro services et des
client) fonctionnalités)
Facilité de Elevée Elevé
Développement (la possibilité d’avoir
plusieurs équipe qui
travail chacun sur une
fonctionnalité du
système)
Lien Non Oui Oui
Serveur-
serveur
Flexibilité Limitée Moyenne Totale
D’architecture
Matériel
Relève en cas Faible Excellente Excellente
de pannes (Possibilité d'avoir la (Facile à détecter et a
couche du centre résoudre, il suffit de
"middle-tier" sur vérifier le micro
plusieurs serveurs) service concerné)
b. Justification et présentation de l’architecture choisie
D’après le tableau ci-dessous il est indéniable que l’architecture Micro service est
la mieux adaptée pour notre système au vu de ses nombreux avantages. Le micro service
est une méthode de développement d’applications logicielles en tant que suite de services
modulables et indépendamment, dans lesquels chaque service exécute un processus qu’il
communique à travers un mécanisme défini au préalable. L'architecture Micro service, est
une architecture client-serveur dans laquelle coexistent et sont maintenus des modules
indépendants permettant le rendu d'une interface utilisateur (GUI), les process logiques,
fonctionnels et métiers ainsi que l'accès aux données. On parle donc ici d'une infrastructure
physique qui va servir de support à une infrastructure logicielle. En effet, n'importe quelle
application peut être découpée en micro services.
La couche de présentation : C'est la première couche qui compose l'infrastructure

micro service : il s'agit de la partie rendu logiciel. Elle est rendue possible grâce aux
langages de rendus, en l'occurrence pour une application mobile, le XAML le C# pour
ajouter une partie fonctionnelle à ce rendu.

La couche Métier ou Fonctionnelle : C'est la seconde couche qui compose
l'infrastructure micro service : elle correspond à un ensemble de composants métiers qui
permettent de traiter un ensemble d'actions sur un serveur, et de faire éventuellement appel
à des services externes pour envoyer une réponse au client. Le client communique donc
avec le serveur grâce à l'interface graphique, puis le serveur fait son traitement et renvoie
la réponse au client.
La couche d'accès aux données : C'est la troisième couche qui compose

l'infrastructure micro service : elle correspond au serveur de base de données. Il s'agit de la
couche d'accès aux données. Sur cette troisième couche, un SGBD (Système de Gestion de
Base de Données) est installé, comme par exemple PostgreSQL, Microsoft SQL Server, et
ce serveur est requêté par le serveur applicatif afin d'utiliser un certain nombre de donnée.
Figure 20-architecture micro service source : https://www.redhat.com/fr/topics/microservices/what-are-

microservices

c. Architecture physique de notre application
Serveur
Web &&
Serveur
d applicatio
n
Administrateur
Collecte des données géographique
VIP
Reverse Proxy
Figure 21-architecture physique de l'application
Diagramme de classe
a. Présentation du diagramme de classe
Le diagramme de classe constitue un élément très important de la modélisation : il

permet de définir quelles seront les composantes du système final. Il ne permet en revanche pas
de définir le nombre et l’état des instances individuelles. Néanmoins, on constate souvent qu’un
diagramme des classes proprement réalisé permet de structurer le travail de développement de
manière très efficace ; il permet aussi, dans le cas de travaux réalisés en groupe (ce qui est
pratiquement toujours le cas dans les milieux industriels), de séparer les composantes de
manière à pouvoir répartir le travail de développement entre les membres du groupe. Enfin, il
permet de construire le système de manière correcte.

b. Elément constitutifs d’un diagramme de classe

Tableau 18-élement constitutifs d'un diagramme de classe
Eléments Noms & rôle
Classe : Ensemble d’élément de

même nature pouvant être identifié de façon
unique
Attributs Ensemble d’élément caractérisant un

objet
Méthode () Fonction de la classe
Relation entre 2 classes
Multiplicité d’une classe
c. Formalisme
Figure 22-formalisme du diagramme de classe
d. Règles de gestion
Notre système d’adressage devra respecter les règles de gestion suivante :
➢ Un utilisateur peut générer une ou plusieurs adresses

➢ Une adresse appartient à un et un seul utilisateur
➢ Un abandon concerne une et une seule adresse
➢ Une adresse est abandonnée une seul fois
➢ Une adresse appartient à une ou plusieurs types

➢ Un type d’adresse peut avoir aucun ou plusieurs adresses
➢ Un terrain appartient à un seul utilisateur
➢ Un utilisateur peut avoir plusieurs terrains
e. Liste des attributs et classes
Pour construire notre diagramme de classe, nous allons tout d’abord répertorier dans un
tableau les classes ainsi que les attributs dont nous aurons besoin.
Tableau 19-liste des attributs et classes de notre système
Classe Attribut Description Type
Utilisateur IdUtilisateur Identifiant utilisateur String
NomUtilisateur Nom de l’utilisateur string
PrenomUtilisateur Prénom de l’utilisateur string
EmailUtilisateur Adresse mail de l’utilisateur string
Numero utilisateur Telephone de l’utilisateur string
UserName Identifiant de connexion de l’utilisateur string
MotDePass Mot de passe de l’utilisateur String
Sexe Sexe de l’utilisateur String
Adresse IdAdresse Identifiant de l’adresse String
NumeroRue Numéro de la rue Int
NomRue Nom de la rue de l’utilisateur String
NumeroDepartement Numéro du département dans lequel se Int

trouve l’utilisateur
NomCommun Nom de la commune de l’utilisateur String
Longitude Longitude de l’utilisateur Double
Latitude Latitude de la position de l’utilisateur Double
Altitude Altitude de la position de l’utilisateur Double
IsCertify Etat de certification de l’adresse Bool
Accesibilite Défini si une adresse est visible par String

d’autre utilisateur ou pas

DateDemande Date à laquelle l’utilisateur à demande DateTime

son adresse
DateAttribution Date à laquelle l’adresse est rattaché à DateTime

l’utilisateur
DateCertification Date à laquelle l’adresse a été certifiée DateTime
Libelle Libelle de l’adresse String
Description Titre de l’adresse(bureau, domicile…) String
NumeroAppartement Numéro de l’appartement de l’utilisateur Int
NumeroChambre Numéro de chambre de l’utilisateur Int
Terrain IdTerrain Identifiant du terrain dans le système String
Intitule Libelle du terrain String
Shape Suite de donne représentant le terrain( String
Dimension Nombre de mètre carre du terrain Double
Role IdRole Identifiant d’un rôle String
NomRole Nom du rôle String
Abandon IdAbandon Identifiant d’un abandon d’adresse String
Motif Motif de l’utilisateur pour abandonner String

l’adresse
DateAbandon Date de l’abandons DateTime

f. Représentation du diagramme de classe
Figure 23-diagramme de classe de l'application
Diagramme d’état transition
a. Présentation du diagramme d’état transition
Les diagrammes d’état sont utilisés pour documenter les diverses mode (état) qu’une
classe peut prendre, et les évènements qui causent une transition d’état. Ils ont pour rôle de
présenter les traitements (opérations) qui vont gérer le domaine étudié. Ils définissent
l’enchainement des états de classe et font donc apparaitre l’ordonnancement des travaux.
b. Eléments constitutif du digramme d’état transition

Tableau 20-élément constitutif du diagramme d'état transition
Éléments Descriptions

État Final : Représente la destruction de l’objet que nous

modélisons.
État Initial : C’est l’état d’un objet avant toute transition
Transition ou événement : Décrit le changement d’état

d’un objet, provoqué par un événement.
État : Correspond à une situation durable dans laquelle se

trouvent les objets d’une classe. État=objet d’une classe + règle
de gestion + changement d’état.
c. Formalisme
Figure 24-formalisme du diagramme d'état transition

d. Représentation du diagramme d’état transition de

notre système
✓ Cas d’état transition adresse
<<complétion des
information>>
En cours en attente
<<créer une adresse>>

<<annuler>>
<<valider>>
Enregistrer
Valider
<<enregistrer>>
Figure 25-diagramme d'état transition d'une adresse
✓ Cas de la recherche d’adresse
<<recuperation des resultat>> reussi
<<lancer>>
en cour
<<annuler>>
echec
<<pas de correspondance>>

II. CONCEPTION GENERIQUE
Prototypage de l’application
Figure 26-prototype de l'Application

Conclusion
Dans ce dossier de conception, nous avons mené une analyse en ressortant les données
validées et les traitements à automatiser. Cette validation nous permet d’avoir une vision sur le
logiciel à mettre sur pied. En d’autres termes, les traitements validés vont constituer les
différents modules de l’application. Les données quant à elles vont servir pour la création de la
base de données. Des lors, l’étape suivante de notre projet sera la réalisation de la solution
proprement dite en tenant compte de tous les paramètres analyses et de conception ci-dessus.

DOSSIER IV. RÉALISATION
RÉSUMÉ
Cette phase consiste à la mise en œuvre du projet dans un langage de programmation

conformément aux spécifications définies dans les phases précédentes. Elle renferme en son
sein les diagrammes de composant et de déploiement ; les phases de test et de mise au point
(débogage). À la sortie de cette partie, il sera produit une documentation de programmation
expliquant l’architecture de la base de données et l’architecture de notre code.
Aperçu
Introduction
I. Conception Préliminaire
II. Conception Détaillée
III. Choix des Technologies
IV. Codage et Test
Conclusion

Introduction
La conception et la modélisation étant des maillons importants dans le processus de
développement d’une application car elles permettent de définir et spécifier les différents
éléments constituant l’application ou le système étudiés, mais la réalisation est l’étape qui
permet de reproduire concrètement les différents objets issus de la conception et de donner vie
au système informatique. Il sera question pour nous tout au long de ce dossier de présenter
l’architecture logicielle, physique et matérielle de notre système, à travers les diagrammes tels
que le diagramme de composant, de déploiement, le modèle physique et l’architecture du code.

I. CONCEPTION PRELIMINAIRE
Diagramme des composants
a. Présentation du diagramme des composants
Un diagramme des composants est un diagramme UML qui fournit une représentation
graphique des dépendances et des généralisations entre composants logiciels, en incluant les
composants de code source, les composants de code binaire et les composants exécutables.
b. Eléments constitutif du digramme des composants

Tableau 21-elements constitutifs du diagramme des composants
Élément Description
Le composant : il représente les

entités logicielles du système.
Dépendance : relation entre les

différents composants logiciels de notre
système
➢ UML définit 5 stéréotypes aux composants :

✓ « Document » : document quelconque ;
✓ « Exécutable » : un programme qui peut s’exécuter ;
✓ « Fichier » : un fichier contenant du code source ou des données ;
✓ « Bibliothèque » : une bibliothèque statique ou dynamique ;
✓ « Table » : une table de base de données relationnelle.
✓ Notion de dépendances
On dit qu’un composant A dépend d’un composant B si et seulement si le composant A
à besoin du composant B pour être exécuté.

c. Formalisme du diagramme des composants
Figure 27-formalisme du diagramme des composants
Figure 28-formalisme du diagramme des composants
d. Représentation du diagramme des composants de

notre système
fichier jpg
fichier.json
fichier png
fichier .xaml
fichier.xaml.cs
fichier.cs
Figure 29-diagramme des composants

Diagramme de déploiement
a. Présentation du diagramme de déploiement
Un diagramme de déploiement est un diagramme UML qui permet de représenter

l’architecture matérielle d’exécution du système. Il permet la représentation des nœuds ou
instances de nœud sur lesquels s’exécutera le système.
b. Eléments constitutifs du diagramme de déploiement
Eléments Description
Le nœud : représentant une entité

Noeud_1 matériel du système.
Le composant : il représente les

entités logicielles du système.
Les associations : représentant les

lignes de communication entre les nœuds du
système.
Figure 30-elements constitutifs du diagramme de déploiement
c. Formalisme du diagramme de déploiement
Figure 31-formalisme du diagramme de déploiement

d. Représentation du diagramme de déploiement de

notre système
Micro service
Utilisateurs
Serveur web
<<call>>
Adresse
serveur IIS <<call>>
<Utiliser>
Sérialisation et désarialisation des

données
client
Android
Serveur de base de données
ios
BD Géographique
BD Adresse
Figure 32-diagramme de déploiement du système
II. CONCEPTION DETAILLEE
La figure ci-dessous présente le model physique de données, c’est un premier aperçu

sur notre base de données.

Terrain
IdUtilisateur integer <fk> UserRole
porter
Id integer <pk> IdUtilisateur integer <fk1>
Intitule integer IdRole integer <fk2>
Shape integer
Dimension integer Utilisateur
...
IdUtilisateur integer <pk>
NomUtilisateur varchar(254)
posserder Role
PrenomUtilisateur varchar(254)
EmailUtilisateur varchar(254) IdRole integer <pk>
NumeroUtilisateur varchar(254) NomRole varchar(254)
UserName varchar(254)
MotDePasse varchar(254)
Genre varchar(254)
...
avoir
Abandons
IdAbandons integer <pk> TypeAdresse
Motif varchar(254) Adresse IdAdresse integer <fk>
DateAbandons timestamp IdType integer <pk>
IdUtilisateur integer <fk1>
CreateAt timestamp Libelle varchar(254)
IdAdresse integer <pk> etre
IsExist smallint Description varchar(254)
... IdAbandons integer <fk2>
CreateAt timestamp
NumeroRue integer
IsExist smallint
NomRue varchar(254) ...
NumeroDepartement integer
NomCommune varchar(254)
concerner Logitude integer
Latitude integer
Altitude integer
IsCertifier smallint
Accesibilite varchar(254)
DAteDemande timestamp
DateAttribution timestamp
DateCertification timestamp
CreateAt timestamp
UpdateAt timestamp
IsExist smallint
Libelle varchar(254)
Description varchar(254)
...
Figure 33-modèle physique de données
III. CHOIX TECHNOLOGIQUE
Dans le cadre de notre projet, nous devons développer un système permettant d'atteindre
les objectifs que nous nous sommes fixés. Pour cela, nous avons opté pour une programmation
orientée objet basée sur les nouvelles technologies de MICROSOFT afin de pouvoir
implémenter certains concepts tel que l'héritage et la réutilisation. Dans ce paragraphe, nous
ferons une présentation des outils et langage de programmation utilisés lors de cette phase.
La technologie ASP.Net Core MVC de Microsoft
Cette architecture présente un certain nombre d’avantages : la séparation entre partie

graphique et code augmente la lisibilité du code et facilite par conséquent sa maintenance ;
d’autre part, elle permet, le cas échéant, de répartir plus facilement le travail entre des graphistes
qui travaillent sur le contenu C# et les développeurs qui se consacrent sur la logique applicative

l’utilisation de langages orientés objet rend les développements plus robustes (Typage fort,
gestion des exceptions) et plus simples à réutiliser (héritage, polymorphisme) l’organisation du
code en gestionnaires d’événements (« exécuter tel code lorsque tel événement survient »),
rendu possible par un mécanisme capable de réaliser des aller-retour (round-trip) entre le
navigateur et le serveur http en conservant les valeurs contenues dans les contrôles, facilite le
développement des application web et des API Web ( web api).
La technologie XAMARIN FORMS de Microsoft
Xamarin est un framework de développement d’application mobile, ayant pour but de

rendre possible la création d’applications mobiles Android, iOS et Windows. Et ce en utilisant
un seul langage : C#, le langage de programmation phare de Microsoft.
Xamarin offre la possibilité d’exploiter à 100% les plateformes mobiles sans devoir
apprendre un langage spécifique à chaque OS mobile. Ainsi, en maîtrisant le langage C#, le
développeur est capable d’écrire pour iOS, Android ou Windows. Xamarin.Forms est une
couche d’abstraction qui permet de développer les interfaces utilisateurs pour les partager à
travers toutes les plateformes.
Utilisé par un nombre important et grandissant de professionnels, il permet de réaliser

des applications mobile, desktop et bien d’autres.
Langage de programmation à utiliser
Il existe une multitude de langages de programmation ; ce que nous avons choisis pour
la réalisation de notre projet c’est le C# qui est un langage de développement puissant et flexible
permettant de créer des applications en mode console et en mode graphique. C# est un langage
impératifs disposant des fonctionnalités de modèles objets complètes. En raison de la richesse
des bibliothèques de C#.NET on désigne parfois comme une plate-forme plus qu'un simple
langage. Les nombreuses notions orientées objets dont dispose ce langage à savoir :
l’encapsulation, l’héritage, le polymorphisme et autre donnent ainsi au développeur la
possibilité de gagner un temps énorme lors de la réalisation des grands travaux et lui permettent
ainsi d’assurer la protection de ces données à l’aide du concept de classe qui ne peuvent être
manipulées que par une méthode membre de la classe.

IV. CODAGE ET TEST
Architecture logicielle
Dès le démarrage du processus, on aura une vue sur l'architecture à mettre en place.
L’architecture d’un système logiciel peut être décrite comme les différentes vues du système
qui doit être construit. L’architecture logicielle équivaut aux aspects statiques et dynamiques
les plus significatifs du système. L’architecture émerge des besoins de l’entreprise, tels qu’ils
sont exprimés par les utilisateurs et autres intervenants et tels qu’ils sont reflétés par les cas
d’utilisation.
Elle subit également l’influence d’autres facteurs :
✓ La plate-forme sur laquelle devra s’exécuter le système ;

✓ Les briques de bases réutilisables disponibles pour le développement ;
✓ Les considérations de déploiement, les systèmes existants et les besoins non fonctionnels
(performance, fiabilité.).
a. Architecture MVC
L’architecture MVC (modèle vue contrôleur) est un concept très puissant qui
intervient dans la réalisation d’une application. Son principal intérêt est la séparation des
données (modèle), de l’affichage (vue) et des actions. Comme le présente la figure ci-
après :
Figure 34-architecture MVC

L’architecture MVC est donc décomposée en trois étapes :
Le Modèle : Le modèle correspond aux données dans une base de données. Mais
celles-ci peuvent être également contenues dans un fichier XML ou dans des fichiers textes.
Les données peuvent être exploiter sous forme de classe, dans un langage de
programmation orienté objet.
Le Contrôleur : Le contrôleur est l’élément qui va utiliser les données pour les
envoyer à la vue. Son rôle est donc de récupérer les informations, de les traiter en fonction
des paramètres demandés par la vue (par l’utilisateur, exemple : afficher les derniers
articles), puis de renvoyer à la vue les données afin qu’elles soient affichées. Le contrôleur
peut donc instancier différents objets (Classe User, classe Articles, …) qui enverront des
requêtes vers la base des données ou récupéreront des données XML. La transmission à la
vue des données récupérées se fait généralement à l’aide d’un Template : insertion des
données dans un fichier XAML qui va être envoyé à l’utilisateur.
La Vue : La vue correspond à un fichier XAML la plupart du temps (peut être un

fichier XML avec une feuille de style XSL). Elle se contente d’afficher le contenu qu’elle
reçoit sans avoir connaissance des données. Elle ne contient que les informations liées à
l’affichage. Dans le cas d’une page XAML, elle contient les éléments <Grid>, <Title>,
<Textbox> … dans lesquels vont venir s’insérer les contenus.
b. Architecture MVVM
la méthodologie Modèle / Vue / Vue-Modèle est une variation du patron de

conception MVC, taillée sur mesure pour les technologies modernes d’interface utilisateur
où la réalisation de la Vue est davantage confiée à un designer qu’à un développeur
classique. Ce pattern identifie trois objets distincts, la plus pertinente est : La Vue –
Modèle : ce composant fait le lien entre le modèle et la vue. Il s’occupe de gérer les liaisons
de données et les éventuelles conversions. C’est ici qu’intervient le binding.
Là où le pattern MVVM va vraiment apporter une plus-value est dans des projets
contenant de nombreuses interfaces utilisateur. Souvent, on voit une UI (Window, Page,
UserControl) avec un présentateur de données et un fichier de code-behind pour les évents.
En appliquant MVVM sur un tel projet, non seulement vous réduisez le nombre de fichiers
à charger par Visual Studio et le compilateur (il n’y a que très rarement besoin d’un fichier

de code-behind), mais vous gagnez également en lisibilité dans l’explorateur de solution
en n’étant plus obligé de switcher entre code-behind(évents) et présentateurs(données).
Nous pouvons résumer cette architecture suivant les points suivants :
✓ La View est décrite en XAML de façon purement déclarative. Elle dispose tout de
même d'un code-behind dans lequel on peut coder en C#, mais cela doit se limiter
à du code lié à l'affichage (déclencher une animation par exemple).
✓ Le Model est la représentation d'une donnée, au sens métier du terme.
✓ Le ViewModel est la couche intermédiaire qui prépare les données et les expose à
la View. C'est généralement là qu'on trouvera la logique de validation des données,
l'exécution des calculs, l'appel aux différents services...
Figure 356ARCHITECTURE MVVM
Les web services (services web)
a. Definition et Presentation
Un service Web est un programme informatique permettant la communication et

l'échange de données entre applications et systèmes hétérogènes dans des environnements
distribués. Il s'agit donc d'un ensemble de fonctionnalités exposées sur internet ou sur un
intranet, par et pour des applications ou machines, sans intervention humaine, et en temps
réel.
Les services Web fournissent un lien entre applications. Ainsi, des applications
utilisant des technologies différentes peuvent envoyer et recevoir des données au travers
de protocoles compréhensibles par tout le monde.

Les services Web sont normalisés car ils utilisent les standards XML et HTTP pour
transférer des données et ils sont compatibles avec de nombreux autres environnements de
développement. Ils sont donc indépendants des plates-formes. C'est dans ce contexte qu'un
intérêt très particulier a été attribué à la conception des services Web puisqu'ils permettent
aux entreprises d'offrir des applications accessibles à distance par d'autres entreprises. Cela
s'explique par le fait que les services Web n'imposent pas de modèles de programmation
spécifiques. En d'autres termes, les services Web ne sont pas concernés par la façon dont
les messages sont produits ou consommés par des programmes. Cela permet aux vendeurs
d'outils de développement d'offrir différentes méthodes et interfaces de programmation au-
dessus de n'importe quel langage de programmation, sans être contraints par des standards
comme c'est le cas de la plate-forme CORBA qui définit des ponts spécifiques entre le
langage de définition IDl et différents langages de programmation. Ainsi, les fournisseurs
d'outils de développement peuvent facilement différencier leurs produits avec ceux de leurs
concurrents en offrant différents niveaux de sophistication.
Les services Web représentent donc la façon la plus efficace de partager des
méthodes et des fonctionnalités. De plus, ils réduisent le temps de réalisation en permettant
de tirer directement parti de services existants.
b. Caractéristiques
La technologie des services Web repose essentiellement sur une représentation

standard des données (interfaces, messageries) au moyen du langage XML. Cette
technologie est devenue la base de l'informatique distribuée sur Internet et offre beaucoup
d'opportunités au développeur Web.
Un service Web possède les caractéristiques suivantes :
✓ Il est accessible via le réseau ;

✓ Il dispose d'une interface publique (ensemble d'opérations) décrite en XML ;
✓ Ses descriptions (fonctionnalités, comment l'invoquer et où le trouver ?) sont
stockées dans un annuaire ;
✓ Il communique en utilisant des messages XML, ces messages sont transportés

par des protocoles Internet (généralement HTTP, mais rien n'empêche d'utiliser
d'autres protocoles de transfert tels : SMTP, FTP, BEEP...) ;

✓ L'intégration d'application en implémentant des services Web produit des

systèmes faiblement couplés, le demandeur du service ne connaît pas forcément
le fournisseur.
✓ Ce dernier peut disparaître sans perturber l'application cliente qui trouvera un

autre fournisseur en cherchant dans l'annuaire.
c. Architecture d’un web service
Les services Web reprennent la plupart des idées et des principes du Web (HTTP,
XML), et les appliquent à des interactions entre machines. Comme pour le World Wide
Web, les services Web communiquent via un ensemble de technologies fondamentales qui
partagent une architecture commune. Ils ont été conçus pour être réalisés sur de nombreux
systèmes développés et déployés de façon indépendante. Les technologies utilisées par les
services Web sont HTTP, WSDL, REST, XML-RPC, SOAP et UDDI.
d. Fonctionnement d’un web service
Le fonctionnement des services Web s'articule autour de trois acteurs principaux

illustrés par le schéma suivant :
Figure 36-fonctionnement d'un web service

✓ Service provider service : Le fournisseur de service met en application le

service Web et le rend disponible sur Internet.
✓ Service requêter programme client : C'est n'importe quel consommateur du
service Web. Le demandeur utilise un service Web existant en ouvrant une
connexion réseau et en envoyant une demande en XML (REST, XML-RPC, SOAP).
✓ Annuaire services registry : Le registre de service est un annuaire de
services. Le registre fournit un endroit central où les programmeurs peuvent publier
de nouveaux services ou en trouver.
✓ Les interactions entre ces 3 acteurs suivent plusieurs étapes :
✓ La publication du service : le fournisseur diffuse les descriptions de ses
services Web dans l'annuaire.
✓ La recherche du service : le client cherche un service particulier, il
s'adresse à un annuaire qui va lui fournir les descriptions et les URL des services
demandés afin de lui permettre de les invoquer.
✓ L'invocation du service : une fois que le client récupère l'URL et la
description du service, il les utilise pour l'invoquer auprès du fournisseur de services.
e. Description en couche des services web
Les services Web emploient un ensemble de technologies qui ont été conçues afin
de respecter une structure en couches sans être dépendante de façon excessive de la pile
des protocoles. Cette structure est formée de quatre couches majeures :
✓ Couches technologiques des services Web.

✓ Le transport de messages XML-RPC ou SOAP est assuré par le standard
HTTP.
✓ SOAP ou XML-RPC prévoit la couche de communication basée sur XML
pour accéder à des services Web.
✓ La description d'un service Web se fait en utilisant le langage WSDL.

WSDL expose l'interface du service.

✓ La publication et la découverte des services Web sont assurées par le biais

du référentiel UDDI. Un référentiel UDDI est un catalogue de services
Web.
Couche transport : Cette couche est responsable du transport des messages XML
échangés entre les applications. Actuellement, cette couche inclut HTTP, SMTP, FTP, et
de nouveaux protocoles tels que BEEP.
Couche communication : Cette couche est responsable du formatage des données

échangées de sorte que les messages peuvent être compris à chaque extrémité.
Actuellement, deux styles architecturaux totalement différents sont utilisés pour ces
échanges de données. Nous avons d'un côté l'architecture orientée opérations distribuées
(protocoles RPC) basée sur XML et qui comprend XML-RPC et SOAP et de l'autre côté
une architecture orientée ressources Web, REST (Représentationnel State Transfer) qui se
base uniquement sur le bon usage des principes du Web (en particulier, le protocole HTTP).
Couche description de service : Cette couche est responsable de la description de

l'interface publique du service Web. Le langage utilisé pour décrire un service Web est
WSDL qui est la notation standard basée sur XML pour construire la description de
l'interface d'un service. Cette spécification définit une grammaire XML pour décrire les
services Web comme des ensembles de points finaux de communication (ports) à travers
lesquels on effectue l'échange de messages.
Couche découverte de service : Cette couche est chargée de centraliser les

services dans un registre commun, et de simplifier les fonctionnalités de recherche et de
publication des services Web. Actuellement, la découverte des services est assurée par un
annuaire UDDI (Universal Description, Discovery, and Intégration).
f. Architecture micro service
• Définition : Microservice est un style architectural qui structure une application

sous forme d'un ensemble de petits services autonomes modélisés autour d'un
domaine métier. Une grande application peut être divisée en plusieurs services plus
petits. Chaque service effectue sa tâche correspondante pour assurer le bon
fonctionnement de l’ensemble du système. Ces services sont indépendants les uns
des autres. Les microservices facilitent donc le processus de développement.

• Fonctionnement : Microservices permet de diviser l'application en plusieurs
modules ou services de manière faiblement couplée afin qu'ils soient indépendants
les uns des autres. Cela facilite le développement de l'application.
Figure 37-architecture micro services
Outils utilises
Pour mettre sur pied notre solution nous avons utilisé les outils suivants :
Tableau 22-les outils utilises
Outils Rôle
Visual Studio Community 2017 : qui

est notre environnement de développement
Microsoft SQL serveur 2012 : qui est

notre système de gestion de base de données
Microsoft IIS 6.0 : qui représente ici

notre serveur d’application
Outils de test des API
PowerAMC 15.4 : utilisé pour la

modélisation de nos différents diagrammes

Microsoft Office : pour l’édition de

notre document
Technologie pour le developpement

des API
Linq sql pour les requêtes avec la

base de donne
Navigateur web
Plateforme sur laquelle nous avons

développé l’ensemble de nos application
Microsoft Entity Framework 6.2 :

qui est notre ORM utilisé pour le mapping
de notre base de données
Prototypage des differents interfaces

de l’application mobile
Logiciel SIG (système d'information

géographique) libres

Les langages de programmation utilisés

Tableau 23-les langages de programmation utilisés
LANGAGE RÔLE
Langage de programmation utilisé

pour l’édition de l’application mobile
Langage utilisé pour la mise en

forme des pages de l’application mobile
langage de définition, de manipulation, de

contrôle des données et d’interrogation de la
base de données, il est notamment très utilisé
pour communiquer avec les données d’un
site web.

Conclusion
Dans cette partie nous avons abordé plusieurs notions tour à tour l’architecture
logicielle, matérielle, les ressources matérielles et logicielles entrant dans le projet. A la
question de savoir comment sera déployée notre application, des éléments de réponses ont été
apporté au travers des diagrammes tels que le diagramme du déploiement. Parvenu donc au
terme de cette phase de notre cycle de développement, il est important de se poser la question
de savoir si les utilisateurs du futur système seront à même de l’utiliser sans éprouver de
difficultés ? La réponse à cette question fera l’objet de la prochaine phase qui est : le Guide
Utilisateur.

DOSSIER V. GUIDE D’UTILISATION
Résume
Le guide d’utilisation a pour but d’apporter à l’utilisateur de l’application l’aide

nécessaire concernant son installation et son utilisation. Il garantit entre autres une
exploitation complète et sans difficulté de celui-ci pas son utilisateur.
Aperçu
Introduction
I. Guide de déploiement
II. Guide d’utilisation
Conclusion

Introduction
Le logiciel devrait être fourni avec une documentation qui permettre de faciliter aux
futurs utilisateurs, l’utilisation du logiciel. Le guide d’utilisation a donc pour but d’apporter à
l’utilisateur de l’application l’aide nécessaire concernant son utilisation. Dans cette partie nous
présenterons une vue générale de l’application pour enfin pouvoir l’utiliser de façon plus aisée.

I. GUIDE DE DÉPLOIEMENT
L’application MyAddress est une application mobile téléchargeable depuis le Play store
pour les appareils Android et depuis l’App store pour les appareils iOS. Le déploiement est
donc presque inexistant. Il suffit d’installer l’application et d’utiliser.
II. GUIDE D’UTILISATION
Dans cette partie, les étapes de réalisation des opérations seront expliquées de façon
détaillée. Tout ceci sera fait à travers des test et des explications avec des captures d’écran à
l’appui afin de permettre aux utilisateurs non seulement de savoir comment faire réellement des
manipulations, mais aussi pour les permettre d’avoir un aperçu des résultats auxquels ils doivent
s’attendre.
Création d’un compte
Pour pouvoir utiliser les fonctionnalités qu’offre l’application, les utilisateurs doivent
s’authentifier avec leur numéro de téléphone et leur mot de passe. La capture d’écran suivante
montre comment d’inscrire afin de pour bénéficier d’un accès à l’application et ses
fonctionnalités.

Figure 38-inscription à Myaddress

Connexion à l’application
La connexion à l’application se fait via le numéro de téléphone et le mot de passe. Apres

la connexion l’utilisateur est dirigé vers l’accueil de l’application
Figure 39-connexion à myaddress

Demander une adresse
La demande d’adresse se fait via le Button + en bas à droite de la page d’accueil. Une
fois que l’utilisateur clic sur +, une adresse est générée et affiché avec quelque champ en plus
à compléter. Il s’agit de la visibilité de l’adresse, le numéro de chambre ou d’appartement et le
type d’adresse,
Figure 40-génération d'adresse
L’adresse générée par le système est constituée dans l’ordre du :
• Le numéro de la région
• Le numéro du département

• Le nom de la commune
• Le numéro de l’habitation (qui est la distance entre la maison et l’entrée de la
rue
• Le numéro de la rue
Recherche d’adresse
Il s’suffît d’entrer le numéro de téléphone d’un contact pour retrouver son adresse.
Figure 41-Rechercher une adresse

Navigation
La navigation permet de se rendre à une adresse. L’utilisateur dispose de deux options.

Tout d’abord dans l’onglet navigation en entrant un numéro dans la barre de recherche ou alors
dans l’onglet recherche en cliquant sur le bouton naviguer après une recherche.
➢ Après une recherche
Figure 42-navigation dans myadresse

➢ Dans l’onget navigation de l’application
Figure 43-navigation dans myadresse via l'onget navigation

Conclusion
Parvenue au terme de cette partie ou il était question pour nous de mettre à la disposition
des utilisateurs un guide d’utilisation pour nos différentes plateformes, il en ressort que le guide
utilisation à travers le guide d’installation et d’utilisation constitue l’une des clés de réussite de
notre application en ce sens qu’elle permet une exploitation optimale des fonctionnalités de
notre système.

CONCLUSION GÉNÉRALE
L’évolution exponentielle des innovations et des rénovations dans le domaine des
Nouvelles Technologies est telle que l’on ne sait plus où s’arrête le nouveau et où commence
le déjà « ancien ». Cette réflexion sur la Mise Sur Pied d’un Système d’adressage numérique
ne peut donc avoir qu’une conclusion provisoire car chacun des éléments cités dans ce rapport
de stage continue d’évoluer en permanence. Ainsi, nous avons effectué notre stage au sein de
l’entreprise CLOUD OF ENGINEER FOR SOCIAL DEVELOPMENT S.A. Lors de ce
stage de ces 4 mois, nous avons pu mettre en pratique nos connaissances théoriques acquises
durant notre formation à l’Institut Africain d’Informatique. De plus, nous nous sommes
confrontés aux difficultés réelles du monde du travail et de la gestion des projets informatiques.
Après notre rapide intégration dans l’équipe, nous avons eu l’occasion de réaliser plusieurs
tâches dont la principale aura été la Mise Sur Pied d’un Système d’adressage numérique Qui
d’après nous permettra de résoudre de nombreux problèmes concernant le repérage, la livraison
à domicile et l’orientation des populations. Il constitue désormais une expérience
professionnelle valorisante et encourageante pour notre avenir. Nous pensons que cette
expérience en entreprise nous a offert aussi une bonne préparation à notre insertion
professionnelle car elle aura été enrichissante et complète et nous conforte dans notre désir
d’exercer comme ingénieur dans le domaine de l’informatique. Enfin, nous tenons à exprimer
notre satisfaction d’avoir pu travailler dans de bonnes conditions matérielles et un
environnement agréable et aussi pour notre bonne formation acquise à l’IAI-Cameroun. Nous
pensons pouvoir apporter des innovations l’enregistrement des terrains, la certification des
adresses d’entreprise et de domicile.

BIBLIOGRAPHIE
➢ CATHERINE FARVACQUE-VITKOVIC : Adressage et gestion des villes de 2005

➢ JONATHAN Roux Apprendre le Développeur d'Applications Mobile avec xamarin forms,
cour de 2021.
➢ Thomas LEBRUN Apprendre à développer en c# publié en 2018 ;
➢ SAMIRGC Apprendre le de développement mobile avec Xamarin Forms et MVVM;
➢ Evan BOISSONNOT Maitriser web api REST avec asp.net core dotnet 5.0 publié en
fevrier 2021 ;
➢ Cours uml 1.4 de M ANGA ;
➢ Cours Redaction Scientifique 2021 de Mme IPEM Arlette ;
➢ Guide d’adressage : Mettre en place une démarche d’adressage ; Nommer et numéroter
ses voies Août 2019.

d’excellence technologique PAUL BIYA. Année Académique : 2020-2021 ii
WEBOGRAPHIE
✓ Adresse postale — Wikipédia (wikipedia.org) : le 2 juin 2021

o Objectif : structure d’une adresse
✓ Subdivision territoriale du Cameroun — Wikipédia (wikipedia.org) : le 3 juin 2021.

o Objectif : Subdivision territoriale du Cameroun
✓ Dénomination des rues : l’orientation des populations en question (cameroon-
tribune.cm) : le 1 juillet 2021.
o Objectif : orientation , dénomination des rues au cameroun
✓ Projet d’adressage de la ville de Yaoundé – Communauté Urbaine de Yaoundé
(yaounde.cm) : le 2 juillet 2021.
o Objectif : projet d’adressage de la ville de yaoundé
✓ [Xamarin.Forms] MVVM - A quoi ça sert ? - Sylvain Moingeon : le 2 AOUT 2021.

o Objectif : comprendre le pattern MVVM
✓ Architectures micro-services : objectifs, bénéfices et défis - Partie 1 (technologies-
ebusiness.com) le 20 juin 2021
o Objectif : comprendre l’architecture micro-services
✓ Glossaire des SIG - Base de données géographiques (emse.fr) le 20 juillet
o Objectif : comprendre les base de données géographiques.
✓ Manuel d’utilisation de QGIS — Documentation QGIS Documentation le 12 juillet

o Objectif : guide d’utilisation du logiciel QGIS
✓ 16.4. Lesson: Requêtes Spatiales (qgis.org) le 20 juillet 2021
o Objectif : apprendre les requêtes spatiales
✓ Spatial Queries In Entity Framework Core (c-sharpcorner.com) le 21 juillet 2021

o Objectif: Spatial Queries In Entity Framework Core

d’excellence technologique PAUL BIYA. Année Académique : 2020-2021 iii
TABLE DES MATIERES
Dédicace ....................................................................................................................... III
Remerciements ............................................................................................................. IV
Sommaire....................................................................................................................... V
Liste des tableaux ...................................................................................................... VIII
Liste des figures ............................................................................................................. X
Liste des abréviations ................................................................................................ XIII
Résumé ...................................................................................................................... XIV
Abstract........................................................................................................................XV
Introduction Générale ..................................................................................................... 2
PARTIE I : PHASE d’insertion ...................................................................................... 3
Introduction .................................................................................................................... 4
I. Accueil et insertion dans l’entreprise ........................................................... 5
Accueil ..................................................................................................... 5
Intégration dans l’entreprise .................................................................... 5
II. Présentation de la structure ......................................................................... 5
Historique................................................................................................. 5
Présentation des services ......................................................................... 6
Présentation des produits de CESD SA ................................................... 7

d’excellence technologique PAUL BIYA. Année Académique : 2020-2021 iv
Situation géographique .......................................................................... 10
Structure hiérarchique de CESD SA ...................................................... 11
III. Ressources matérielles et logicielles de CESD SA ................................. 11
Ressources matérielles ........................................................................... 11
Ressources logicielles ............................................................................ 12
Architecture réseau de CESD SA .......................................................... 13
IV. Présentation du thème .............................................................................. 14
Conclusion .................................................................................................................... 15
PARTIE II : Phase technique ....................................................................................... 16
DOSSIER I. CAHIER DES CHARGES ............................................................... 17
Introduction .................................................................................................................. 18
I. Contexte et justification du projet .............................................................. 19
II. Objectifs du projet ..................................................................................... 19
Objectif général du projet ...................................................................... 19
Objectif spécifique ................................................................................. 19
III. Cibles ....................................................................................................... 20
IV. Expression des besoins ............................................................................ 20
Besoins fonctionnels .............................................................................. 20
Besoins non fonctionnels ....................................................................... 21
V. Intervenants ............................................................................................... 22
VI. Etude financière du projet ....................................................................... 22

d’excellence technologique PAUL BIYA. Année Académique : 2020-2021 v
Ressources humaines ............................................................................. 22
Ressources matérielles ........................................................................... 22
Ressources logicielles ............................................................................ 23
Estimation du coût du projet .................................................................. 24
VII. Planification du projet ............................................................................ 25
Déroulement........................................................................................... 25
Planification des taches .......................................................................... 25
Diagramme de Gantt .............................................................................. 26
VIII. Contraintes ............................................................................................ 27
IX. Livrables .................................................................................................. 27
Conclusion .................................................................................................................... 28
DOSSIER II. ANALYSE ...................................................................................... 29
Introduction .................................................................................................................. 30
I. Description de l’existant ............................................................................. 31
L’adressage au Cameroun ...................................................................... 31
Etude des systèmes de numérotation existants ...................................... 31
a. Le Système continu ................................................................................................... 31
b. Le système métrique ................................................................................................. 32
II. Critique de l’existant ................................................................................. 32
III. Problématique .......................................................................................... 33
IV. Présentation de la Solution proposé ........................................................ 33
V. Présentation de la démarche d’analyse ..................................................... 34

d’excellence technologique PAUL BIYA. Année Académique : 2020-2021 vi
Etude comparative entre UML et MERISE ........................................... 34
Justification de la méthode choisie ........................................................ 35
Présentation du langage UML ............................................................... 35
a. Historique .................................................................................................................. 35
b. Description ................................................................................................................ 36
Présentation du processus choisi............................................................ 37
Présentation du processus unifié 2TUP ................................................. 37
VI. MODÉLISATION DE LA SOLUTION ................................................. 39
Diagramme de cas d’utilisation ............................................................. 39
c. Éléments constitutifs du diagramme de cas d’utilisation ......................................... 39
d. Formalisme du diagramme de cas d’utilisation ........................................................ 40
e. Identification Des Acteurs Et Des Cas D’Utilisations ................................................. 40
f. Représentation du diagramme de cas d’utilisation utilisateur ................................. 42
g. Représentation du diagramme de cas d’utilisation globale ...................................... 43
h. Description textuelle des cas d’utilisation................................................................. 43
Diagramme de séquence ........................................................................ 46
a. Présentation du diagramme de séquence ................................................................ 46
b. Eléments constitutifs du diagramme de séquence ................................................... 46
c. Formalisme du diagramme de séquence .................................................................. 48
d. Représentation des diagrammes de séquence ......................................................... 49
Diagramme d’activité ............................................................................ 53
a. Présentation du diagramme de classe ...................................................................... 53
b. Eléments constitutif du diagramme d’activité .......................................................... 54
c. Formalisme du diagramme d’activité ........................................................................ 54
d. Représentation du diagramme d’activité .................................................................. 55

d’excellence technologique PAUL BIYA. Année Académique : 2020-2021 vii
Conclusion .................................................................................................................... 57
DOSSIER III. CONCEPTION .............................................................................. 58
Introduction .................................................................................................................. 59
I. Capture des besoins technique.................................................................... 60
Architecture physique de l’application .................................................. 60
a. Comparaisons des architectures ............................................................................... 60
b. Justification et présentation de l’architecture choisie .............................................. 61
c. Architecture physique de notre application.............................................................. 63
Diagramme de classe ............................................................................. 63
a. Présentation du diagramme de classe ...................................................................... 63
b. Elément constitutifs d’un diagramme de classe ....................................................... 64
c. Formalisme ................................................................................................................ 64
d. Règles de gestion ....................................................................................................... 64
e. Liste des attributs et classes ...................................................................................... 65
f. Représentation du diagramme de classe .................................................................. 67
Diagramme d’état transition .................................................................. 67
a. Présentation du diagramme d’état transition........................................................... 67
b. Eléments constitutif du digramme d’état transition ................................................. 67
c. Formalisme ................................................................................................................ 68
d. Représentation du diagramme d’état transition de notre système ......................... 69
II. Conception générique................................................................................ 70
Prototypage de l’application .................................................................. 70
Conclusion .................................................................................................................... 71
DOSSIER IV. RÉALISATION ............................................................................. 72

d’excellence technologique PAUL BIYA. Année Académique : 2020-2021 viii
Introduction .................................................................................................................. 73
I. Conception préliminaire ............................................................................. 74
Diagramme des composants .................................................................. 74
a. Présentation du diagramme des composants ........................................................... 74
b. Eléments constitutif du digramme des composants ................................................. 74
c. Formalisme du diagramme des composants ............................................................ 75
d. Représentation du diagramme des composants de notre système ......................... 75
Diagramme de déploiement ................................................................... 76
a. Présentation du diagramme de déploiement ........................................................... 76
b. Eléments constitutifs du diagramme de déploiement .............................................. 76
c. Formalisme du diagramme de déploiement ............................................................. 76
d. Représentation du diagramme de déploiement de notre système .......................... 77
II. Conception détaillée .................................................................................. 77
III. Choix technologique ................................................................................ 78
La technologie ASP.Net Core MVC de Microsoft ................................ 78
La technologie XAMARIN FORMS de Microsoft ............................... 79
Langage de programmation à utiliser .................................................... 79
IV. Codage et test .......................................................................................... 80
Architecture logicielle............................................................................ 80
a. Architecture MVC ...................................................................................................... 80
b. Architecture MVVM .................................................................................................. 81
Les web services (services web) ............................................................ 82
a. Definition et Presentation ......................................................................................... 82
b. Caractéristiques ......................................................................................................... 83

d’excellence technologique PAUL BIYA. Année Académique : 2020-2021 ix
c. Architecture d’un web service................................................................................... 84
d. Fonctionnement d’un web service ............................................................................ 84
e. Description en couche des services web ................................................................... 85
f. Architecture micro service ........................................................................................ 86
Outils utilises ......................................................................................... 87
Les langages de programmation utilisés ................................................ 89
Conclusion .................................................................................................................... 90
DOSSIER V. GUIDE D’UTILISATION .............................................................. 91
Introduction .................................................................................................................. 92
I. Guide de déploiement ................................................................................. 93
II. Guide d’utilisation..................................................................................... 93
Création d’un compte............................................................................. 93
Connexion à l’application ...................................................................... 95
Demander une adresse ........................................................................... 96
Recherche d’adresse .............................................................................. 97
Navigation .............................................................................................. 98
Conclusion .................................................................................................................. 100
Conclusion générale ................................................................................................... 101
bibliographie ................................................................................................................... ii
webographie .................................................................................................................. iii
table des matieres .......................................................................................................... iv
annexes .......................................................................................................................... xi

d’excellence technologique PAUL BIYA. Année Académique : 2020-2021 x
ANNEXES
ANNEXE 1 : Fiche d’accord du centre d’accueil
ANNEXE 2 : Planning prévisionnel
ANNEXE 3 : Compte rendu bimensuel
ANNEXE 4 : Fiche d’évaluation
ANNEXE 5 : Normes de rédaction des rapports

d’excellence technologique PAUL BIYA. Année Académique : 2020-2021 xi

RapportJulesIAIL2 Final Du Dimanche

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

RapportJulesIAIL2 Final Du Dimanche

Transféré par

Droits d'auteur :

Formats disponibles

INSTITUT AFRICAIN D’INFORMATIQUE CLOUD OF ENGINEERS FOR

REPRESENTATION DU CAMEROUN SOCIAL DEVELOPMENT S.A

B.P: 3719 Yaoundé B.P: 3719 Yaoundé

Tel: (+237) 242 72 99 58 Tel: (+237) 697 892 096

Site Web: https://iaicameroun.com/ Site Web: https://cesd-sa.com/

E-mail : iaicameroun@yahoo.fr E-mail : contact@cesd-sa.com

THEME : MISE SUR PIED D’UN SYSTÈME

Stage effectué du 02 Juin au 30 Septembre 2021, en vue de l’obtention du Diplôme de

M. NDOUMI Nynke François M. MOMO Arnaud

Année Académique 2020-2021

MEKONTSO Jules Auffred étudiant en deuxième année à l’IAI-Cameroun, centre

MEKONTSO Jules Auffred étudiant en deuxième année à l’IAI-Cameroun, centre

La réalisation de ce rapport de stage a été possible grâce au concours de plusieurs

✓ Monsieur Armand Claude ABANDA, Représentant Résident de l’institut Africaine

✓ Tout le personnel de l’institut Africaine d’informatique (IAI-Cameroun) pour les

MEKONTSO Jules Auffred étudiant en deuxième année à l’IAI-Cameroun, centre

DÉDICACE .................................................................................................................. III

LISTE DES TABLEAUX ......................................................................................... VIII

LISTE DES FIGURES .................................................................................................. X

LISTE DES ABRÉVIATIONS ................................................................................. XIII

RÉSUMÉ ................................................................................................................... XIV

INTRODUCTION GÉNÉRALE .................................................................................... 2

PARTIE I : PHASE D’INSERTION .............................................................................. 3

I. ACCUEIL ET INSERTION DANS L’ENTREPRISE ................................ 5

II. PRESENTATION DE LA STRUCTURE .................................................. 5

III. RESSOURCES MATERIELLES ET LOGICIELLES DE CESD SA .... 11

IV. PRESENTATION DU THEME .............................................................. 14

PARTIE II : PHASE TECHNIQUE ............................................................................. 16

DOSSIER I. CAHIER DES CHARGES ............................................................... 17

MEKONTSO Jules Auffred étudiant en deuxième année à l’IAI-Cameroun, centre

I. CONTEXTE ET JUSTIFICATION DU PROJET ..................................... 19

II. OBJECTIFS DU PROJET ........................................................................ 19

III. CIBLES .................................................................................................... 20

IV. EXPRESSION DES BESOINS ............................................................... 20

VI. ETUDE FINANCIERE DU PROJET ..................................................... 22

VII. PLANIFICATION DU PROJET ........................................................... 25

VIII. CONTRAINTES ................................................................................... 27

IX. LIVRABLES ........................................................................................... 27

DOSSIER II. ANALYSE ...................................................................................... 29

I. DESCRIPTION DE L’EXISTANT ........................................................... 31

II. CRITIQUE DE L’EXISTANT ................................................................. 32

III. PROBLEMATIQUE ................................................................................ 33

IV. PRESENTATION DE LA SOLUTION PROPOSE ............................... 33

V. PRÉSENTATION DE LA DÉMARCHE D’ANALYSE ......................... 34

VI. MODÉLISATION DE LA SOLUTION ................................................. 39

DOSSIER III. CONCEPTION .............................................................................. 58

MEKONTSO Jules Auffred étudiant en deuxième année à l’IAI-Cameroun, centre

II. CONCEPTION GENERIQUE ................................................................. 70

DOSSIER IV. RÉALISATION ............................................................................. 72

II. CONCEPTION DETAILLEE ................................................................... 77

III. CHOIX TECHNOLOGIQUE .................................................................. 78

IV. CODAGE ET TEST ................................................................................ 80

DOSSIER V. GUIDE D’UTILISATION .............................................................. 91

I. GUIDE DE DÉPLOIEMENT .................................................................... 93

II. GUIDE D’UTILISATION ........................................................................ 93

CONCLUSION .......................................................................................................... 100

CONCLUSION GÉNÉRALE .................................................................................... 101

WEBOGRAPHIE .......................................................................................................... iii

TABLE DES MATIERES ............................................................................................. iv

MEKONTSO Jules Auffred étudiant en deuxième année à l’IAI-Cameroun, centre

Liste des tableaux

Tableau 1-les services de CESD SA .............................................................................. 6

Tableau 2-les produits de CESD SA .............................................................................. 7

Tableau 3-ressources matérielles .................................................................................. 11