UNIVERSITE DE FIANRANTSOA

ECOLE NATIONALE D’INFORMATIQUE

MEMOIRE DE FIN D’ETUDES EN VUE DE L’OBTENTION DU DIPLOME DE LICENCE
PROFESSIONNELLE

Mention : Informatique
Parcours : Génie Logiciel et Base de Données

Conception et développement d’un module

de livraison d’une super application

Présenté le 20 Janvier 2023 par :

Monsieur RAKOTOSON Aina Nirina

Membres du jury :
Président : Monsieur RALAIVAO Jean Christian, Assistant d’Enseignement Supérieur et de
Recherche

Examinateur : Monsieur DIMBISOA William Germain, Docteur en Informatique

Rapporteurs : - Monsieur RABETAFIKA Louis Haja, Maître de Conférences
- Monsieur RAZANAMIHOATRA Jean Christian

Année Universitaire 2021-2022

 CURRICULUM VITAE

Nom : RAKOTOSON Aina Nirina

Age: 22 ans

Adresse : Lot 105 GBis Ankofafa Fianarantsoa

Téléphone:034 81 818 38

Email : ainanirinarak@gmail.com

Formations et Diplômes 

2020-2021 : Troisième année en Licence professionnelle dans le parcours Génie Logiciel et

Base de données à l’Ecole Nationale d’Informatique Fianarantsoa.

2019-2020 : Deuxième année en Licence professionnelle dans le parcours Génie Logiciel et

Base de données à l’Ecole Nationale d’Informatique Fianarantsoa.

2018-2019 : Première année en Licence professionnel dans le parcours Génie Logiciel et Base
de données à l’Ecole Nationale d’Informatique Fianarantsoa.

2017-2018 : Terminale au Collège Saint François Xavier, obtention du baccalauréat série C.

Avec mention Assez Bien.

Stages et Expériences Professionnelles

19 Septembre 2022 - 16 Décembre 2022 : Stage au sein de l’ESN RELIA Consulting.

Thème : Conception et réalisation d’un module de livraison d’une super application.

Technologies utilisées : Angular, Nest.

Octobre 2022 : Premier prix lors de l’hackathon Frontend Awards 2022 (fa-2022.yasai.tech).

Avril 2022 - Octobre 2022: Conception et réalisation de l’application web d’entrée au

concours à l’ENI (concours.eni.mg).

Technologies : React, Nest.

i
 Mars 2021 - Mai 2021 : Conception et réalisation d’une application web pour assurer le suivi
des activités judiciaires au sein d’une brigade.

Technologies : React, Laravel.

Compétences informatiques

Systèmes d’exploitation : Windows, Linux.

Langages de programmation : C/C++, JAVA.

Technologies web: HTML5/CSS3/Javascript, PHP, JSP.

Frameworks: Angular, React, Next, React Native.

Méthodes de modélisation : Merise, 2TUP.

Langage de modélisation : UML.

SGBD : MYSQL, Oracle.

Outils graphiques : Figma.

Connaissances linguistiques

Domaine Aptitude à Aptitude à lire Aptitude à écrire et à Aptitude à parler et

Langue comprendre rédiger communiquer
l’audition oralement
Français TB B AB P NS TB B AB P NS T B AB P NS T B AB P NS
B B
Anglais TB B AB P NS TB B AB P NS T B AB P NS T B AB P NS
B B

Grille d’évaluation : Très Bonne (TB), Bonne (B), Assez Bonne (AB), Passable (P), Niveau
Scolaire (NS).

Loisirs : Passionné par la culture asiatique et les jeux vidéo.

ii
 REMERCIEMENTS

Ce rapport n’aurait pas pu être achevé sans l’aide de certaines personnes. Sur ce, j’adresse
mes sincères remerciements à tous ceux qui m’ont accompagné de loin ou de près à la
réalisation de ce projet, en particulier :

- Monsieur HAJALALAINA Aimé Richard, Docteur HDR, Président de l’Université de

Fianarantsoa pour avoir accepté mon inscription au sein de l’université
- Monsieur MAHATODY Thomas, Docteur HDR et Directeur de l’Ecole Nationale
d’Informatique qui nous a donné l’opportunité de partir en stage afin de consolider nos
connaissances et d’en développer de nouvelles.
- Monsieur RABETAFIKA Louis Haja, Docteur en Informatique, Reponsable des
mentions, qui a accepté de m’encadrer pédagogiquement.
- Monsieur Andréas LOVATIANA, Co-fondateur et CEO de RELIA Consulting de
m’avoir accueilli dans son entreprise.
- Monsieur RAZANAMIHOATRA Jean Christian, de m’avoir guidé le long de ce stage
en tant qu’encadreur professionnel.
- Monsieur DIMBISOA William Germain, docteur en Informatique, qui s’est engagé en
tant qu’examinateur
- Monsieur RALAIVAO Jean Christian, Assistant d’Enseignement Supérieur et de
Recherche, en tant que président des jurys
- Tous les enseignants de l’Ecole Nationale d’Informatique pour les connaissances
qu’ils nous ont transmis durant notre formation théorique.
- Les personnels de RELIA Consulting, pour leur collaboration et leur accueil
chaleureux.
- Finalement, je tiens à remercier mes parents et les membres de la famille de m’avoir
soutenu que ce soit moralement, matériellement et financièrement tout au long de ce
stage.

iii
 LISTE DES TABLEAUX

Tableau 1.Organisation du système de formation pédagogique de l’Ecole................................7

Tableau 2. Liste des formations existantes à l’ENI....................................................................8
Tableau 3. Débouchés professionnels éventuels des diplômés.................................................13
Tableau 4. Moyens nécessaires à la réalisation du projet.........................................................20
Tableau 5. Caractéristiques des ordinateurs utilisés.................................................................20
Tableau 6. Points faibles et points forts du système existant....................................................24
Tableau 7. Tableau de comparaison des solutions proposées...................................................24
Tableau 8. Comparaison méthode Agile...................................................................................27
Tableau 9. Comparaison de la méthode 2TUP et MERISE......................................................30
Tableau 10. Comparaison PHP et NodeJs................................................................................31
Tableau 11. Comparaison entre VueJs, ReactJs et Angular.....................................................32
Tableau 12. Comparaison entre ExpressJs et NestJs................................................................33
Tableau 13. Comparaison entre MySQL et MongoDB............................................................33
Tableau 14. Dictionnaire des données......................................................................................35
Tableau 15. Extrait des messages échangés..............................................................................40
Tableau 16. Priorisation des cas d'utilisation............................................................................43

iv
 LISTE DES FIGURES

Figure 1. Organigramme de l'Ecole Nationale d'Informatique...................................................5

Figure 2. Localisation de RELIA..............................................................................................16
Figure 3. Organigramme de RELIA.........................................................................................18
Figure 4. Chronogramme d’activité..........................................................................................21
Figure 5. Comparaison approche traditionnelle et approche Agile..........................................26
Figure 6. Processus de la méthode SCRUM.............................................................................28
Figure 7. Représentation d’un acteur........................................................................................40
Figure 8. Diagramme de cas d'utilisation..................................................................................42
Figure 9. Diagramme de séquence : « S’authentifier ».............................................................46
Figure 10. Diagramme de séquence : « S'inscrire en tant que livreur »...................................47
Figure 11. Diagramme de séquence : « Voir liste livraisons ».................................................48
Figure 12. Diagramme de séquence : « Afficher détails livraison ».........................................49
Figure 13. Diagramme de séquence : « Confirmer une livraison »..........................................50
Figure 14. Diagramme de séquence : « Modifier trajet ».........................................................51
Figure 15. Modèle du domaine.................................................................................................53
Figure 16. Structure MVC d'Angular.......................................................................................55
Figure 17. Diagramme de séquence de conception : « S'authentifier »....................................56
Figure 18. Diagramme de séquence de conception : « S'inscrire en tant que livreur »............57
Figure 19. Diagramme de séquence de conception: « Consulter liste des livraisons »............58
Figure 20. Diagramme de séquence de conception : « Confirmer livraison »..........................59
Figure 21. Diagramme de séquence de conception : « Modifier trajet »..................................60
Figure 22. Diagramme de classe de conception : « S’inscrire en tant que livreur ».................61
Figure 23. Diagramme de classe de conception : « S'authentifier ».........................................61
Figure 24. Diagramme de classe de conception : « Voir liste livraisons »...............................62
Figure 25. Diagramme de classe de conception : « Voir détails livraison ».............................63
Figure 26. Diagramme de classe de conception : « Confirmer une livraison »........................63
Figure 27. Diagramme de classe de conception : « Modifier trajet ».......................................64
Figure 28. Diagramme de classe de conception globale...........................................................65
Figure 29. Diagramme de paquetage........................................................................................66
Figure 30. Diagramme de déploiement.....................................................................................66
Figure 31. Installation Visual Paradigm...................................................................................68

v
Figure 32. Installation MongoDB.............................................................................................69
Figure 33. Interface MongoDB Compass.................................................................................69
Figure 34. Installation Visual Studio Code...............................................................................70
Figure 35. Interface Visual Studio Code...................................................................................71
Figure 36. Architecture REST..................................................................................................72
Figure 37. Collection Delivery.................................................................................................73
Figure 38. Collection DeliveryMan..........................................................................................73
Figure 39. app.routing.ts...........................................................................................................74
Figure 40. delivery routing.......................................................................................................74
Figure 41. Configuration environnement..................................................................................75
Figure 42. API routes................................................................................................................75
Figure 43. API: GET livraisons en cours..................................................................................76
Figure 44. API: GET livraisons recommandées.......................................................................76
Figure 45. API: GET demandes de livraisons..........................................................................76
Figure 46. Resolver pour les demandes de livraisons...............................................................77
Figure 47. Fonction hydrateRequestDeliveryList()..................................................................77
Figure 48. Interface d'inscription..............................................................................................78
Figure 49. Interface d'authentification......................................................................................79
Figure 50. Menu Trouver livraison...........................................................................................79
Figure 51. Menu Mes livraisons...............................................................................................80
Figure 52. Mobile view.............................................................................................................80
Figure 53. Interface liste livraisons...........................................................................................81
Figure 54. Interface détails d'une livraison...............................................................................82
Figure 55. Offres de l'application.............................................................................................83
Figure 56. Code : récupération des livraisons recommandées................................................xiii

vi
 LISTE DES ABREVIATIONS

2TUP: 2 Tracks Unified Process

API: Application Programming Interface

CMS: Content Management System

CPU: Central Processing Unit

CSS: Cascading Style Sheets

ENI : Ecole Nationale d’Informatique

ESN : Entreprise au Service du Numérique

HTML : HyperText Markup Language

HTTP : HyperText Transfer Protocol

IDE : Integrated Development Environment

IU : Interface Utilisateur

JSON : JavaScript Object Notation

MVC: Model View Controller

REST: Representational State

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

SQL: Structured Query Language

UML: Unified Modeling Language

vii
 SOMMAIRE

CURRICULUM VITAE..............................................................................................................i

REMERCIEMENTS.................................................................................................................iii

LISTE DES TABLEAUX.........................................................................................................iv

LISTE DES FIGURES...............................................................................................................v

LISTE DES ABREVIATIONS................................................................................................vii

SOMMAIRE............................................................................................................................viii

INTRODUCTION GENERALE................................................................................................1

PARTIE I : PRESENTATIONS.................................................................................................2

CHAPITRE 1 : PRESENTATION DE L’ECOLE NATIONALE D’INFORMATIQUE.....3

1.1. Information d’ordre général.........................................................................................3

1.2. Missions et historique..................................................................................................3

1.3. Organigramme institutionnel de l’ENI........................................................................5

1.4. Domaine de spécialisation...........................................................................................6

1.5. Architecture des formations pédagogiques..................................................................7

1.6. Relations de l’ENI avec les entreprises et les organismes...........................................9

1.7. Partenariat au niveau international.............................................................................10

1.8. Débouchés professionnels avec des diplômés...........................................................12

1.9. Ressources humaines................................................................................................14

CHAPITRE 2 : PRESENTATION DE LA SOCIETE RELIA CONSULTING..................15

2.1 Présentation et historique............................................................................................15

2.2. Situation géographique de RELIA.............................................................................15

2.3 Missions de RELIA.....................................................................................................16

2.4 Organisation et fonctionnement de RELIA................................................................16

CHAPITRE 3 : DESCRIPTION DU PROJET.....................................................................19

3.1 Formulation.................................................................................................................19

3.2 Objectif et besoins de l’utilisateur..............................................................................19

viii
 3.3 Moyens nécessaires à la réalisation du projet.............................................................20

3.4 Résultats attendus........................................................................................................20

3.5 Chronogramme...........................................................................................................21

PARTIE II : ANALYSE ET CONCEPTION...........................................................................22

CHAPITRE 4 : ANALYSE PREALABLE..........................................................................23

4.1 Analyse de l’existant...................................................................................................23

4.2 Critique de l’existant...................................................................................................23

4.3 Conception de l’avant-projet.......................................................................................24

CHAPITRE 5 : ANALYSE CONCEPTUELLE..................................................................35

5.1 Dictionnaire de données..............................................................................................35

5.2 Règles de gestion........................................................................................................37

5.3 Représentation et spécification des besoins................................................................37

5.4 Spécifications des besoins techniques........................................................................52

5.5 Modélisation du domaine............................................................................................52

CHAPITRE 6 : CONCEPTION DETAILLEE.....................................................................54

6.1 Architecture du système orientée services..............................................................54

6.2 Diagramme de séquence de conception pour chaque cas d’utilisation.......................55

6.3 Diagramme de classe de conception pour chaque cas d’utilisation............................60

6.4 Diagramme de classe de conception globale..............................................................64

6.5 Diagramme de paquetage............................................................................................65

6.6 Diagramme de déploiement........................................................................................66

PARTIE III : REALISATION..................................................................................................67

CHAPITRE 7 : Mise en place de l’environnement de développement................................68

7.1 Installation et configuration des outils........................................................................68

7.2 Architecture de l’application.......................................................................................71

CHAPITRE 8 : DEVELOPPEMENT DE L’APPLICATION.............................................73

8.1 Création de la base de données...................................................................................73

8.2 Codage de l’application..............................................................................................74

ix
 8.3 Présentation de l’application.......................................................................................78

CONCLUSION...........................................................................................................................x

BIBLIOGRAPHIE.....................................................................................................................xi

WEBOGRAPHIE......................................................................................................................xi

GLOSSAIRE............................................................................................................................xii

ANNEXE.................................................................................................................................xiii

TABLE DE MATIERES.........................................................................................................xiv

RESUME................................................................................................................................xvii

ABSTRACT...........................................................................................................................xvii

x
 INTRODUCTION GENERALE

De nos jours, l’e-commerce évolue sur une compétition à l’échelle mondiale.

L’informatisation des différentes activités est de plus en plus fréquente afin de réduire la
complexité avec le monde du travail. RELIA Consulting est une entreprise au service du
numérique installée à Madagascar. Elle intervient sur le marché local aussi bien que sur le
marché international. D’importants progrès technologiques sont observés aujourd’hui sur le
monde de l’e-commerce, les personnes effectuent leurs courses en commandant sur les sites
web tout en se faisant livrer chez soi.

Dans le cadre de ce mémoire, ayant pour thème « Conception et réalisation d’un

module de livraison d’une super application », le projet que nous allons entreprendre consiste
à élaborer une plateforme de livraison aux besoins des livreurs et des acheteurs. L’objectif du
projet est de mettre en place une application web où les livreurs particuliers à temps plein,
aussi bien que les livreurs à temps partiels pourront effectuer les livraisons des achats via la
plateforme.

Afin de mener à terme cette élaboration, nous utiliserons une architecture

microservices pour les différents modules. Pour le module de livraison, nous utiliserons une
méthode de conception tels qu’un langage de programmation, un SGBD et aussi d’outil de
développement comme IDE.

Le rapport de ce projet se déroulera suivant le plan suivant : dans un premier temps, la

présentation de l’Ecole Nationale d’Informatique suivie de celle de l’ESN RELIA Consulting,
ensuite l’analyse et la conception du projet, et en dernier lieu, sa réalisation.

1
PARTIE I : PRESENTATIONS

2
 CHAPITRE 1 : PRESENTATION DE L’ECOLE NATIONALE
D’INFORMATIQUE

1.1. Information d’ordre général

L’Ecole Nationale d’Informatique, en abrégé ENI, est un établissement

d’enseignement supérieur rattaché académiquement et administrativement à l’Université de
Fianarantsoa.
Le siège de l’Ecole se trouve à Tanambao- Antaninarenina à Fianarantsoa.
L’adresse pour la prise de contact avec l’Ecole est la suivante : Ecole Nationale
d’Informatique (ENI) Tanambao, Fianarantsoa.
Site web : www.eni.mg

1.2. Missions et historique

L’ENI se positionne sur l’échiquier socio-éducatif malgache comme étant le plus

puissant secteur de diffusion et de vulgarisation des connaissances et des technologies
informatiques.
Cette Ecole Supérieure peut être considérée aujourd’hui comme la vitrine et la
pépinière des élites informaticiennes du pays.
L’Ecole s’est constituée de façon progressive au sein du Centre Universitaire Régional
(CUR) de Fianarantsoa.
De façon formelle, l’ENI était constituée et créée au sein du (CUR) par le décret
N° 83185 du 24 Mai 1983, comme étant le seul établissement Universitaire
Professionnalisé au niveau national, destiné à former des techniciens et des Ingénieurs de
haut niveau, aptes à répondre aux besoins et exigences d’Informatisation des entreprises,
des sociétés et des organes implantés à Madagascar.
L’ENI a pour conséquent pour mission de former des spécialistes informaticiens
compétents et opérationnels de différents niveaux notamment :
• En fournissant à des étudiants des connaissances de base en informatique ;
• En leur transmettant le savoir-faire requis, à travers la professionnalisation des
formations dispensées et en essayant une meilleure adéquation des formations par
rapport aux besoins évolutifs des sociétés et des entreprises.

3
 • En initiant les étudiants aux activités de recherche dans les différents domaines
des
Technologies de l’information et de la communication (TIC).
L’implantation de cette Ecole Supérieure de technologie de pointe dans un pays en
développement et dans une Province (ou Faritany) à tissu économique et industriel
faiblement développé ne l’a pourtant pas défavorisée, ni empêchée de former des
spécialistes informaticiens de bon niveau, qui sont recherchés par les entreprises, les
sociétés et les organismes publics et privés sur le marché de l’emploi.
La filière de formation d’Analystes Programmeurs a été mise en place à l’Ecole en 1983,
et a été gelée par la suite en 1996, tandis que la filière de formation d’ingénieurs a été
ouverte à l’Ecole en 1986.
Dans le cadre du Programme de renforcement en l’Enseignement Supérieur
(PRESUP), la filière de formation des Techniciens Supérieurs en Maintenance des
Systèmes des informatiques a été mise en place en 1986 grâce à l’appui matériel et
financier de la Mission Française de coopération auprès de l’Ambassade de France à
Madagascar.
Une formation pour l’obtention de la certification CCNA et / ou NETWORK +
appelée « CISCO Networking Academy » a été créée à l’Ecole en 2002-2003 grâce au
partenariat avec CISCO SYSTEM et l’Ecole Supérieure Polytechnique d’Antananarivo
(ESPA). Cependant, cette formation n’avait pas duré longtemps.
Une formation de troisième cycle a été ouverte à l’Ecole a été ouverte à l’Ecole depuis
l’année 2003 – 2004 grâce à la coopération académique et scientifique entre l’Université de
Fianarantsoa pour le compte de l’ENI et l’Université Paul Sabatier de Toulouse (UPST).
Cette filière avait pour objectif de former certains étudiants à la recherche dans les
différents domaines de l’Informatique, et notamment pour préparer la relève des
Enseignants-Chercheurs qui étaient en poste.
Pendant l’année 2007-2008, la formation en vue de l’obtention du diplôme de Licence
Professionnelle en Informatique a été mise en place à l’ENI avec les deux options suivantes
de formation :
- Génie Logiciel et base de Données.
- Administration des Système et réseaux.
La mise en place à l’Ecole de ces deux options de formation devait répondre au
besoin de basculement vers le système Licence – Master – Doctorat (LMD).

4
 Mais la filière de formation des Techniciens Supérieurs en Maintenance des Systèmes
Informatiques a été gelée en 2009.
En vue de surmonter les difficultés de limitation de l’effectif des étudiants
accueillis à l’Ecole, notamment à cause du manque d’infrastructures, un système de «
Formation Hybride » a été mise en place à partir de l’année 2010. Il s’agit en effet d’un
système de formation semi présentielle et à distance avec l’utilisation de la
visioconférence pour la formation à distance. Le système de formation hybride a été ainsi
créé à Fianarantsoa ainsi qu’Université de Toliara.

1.3. Organigramme institutionnel de l’ENI

Cet organigramme de l’Ecole est inspiré des dispositions du décret N° 83-185 du 23

Mai 1983.
L’ENI est administrée par un conseil d’Ecole, et dirigée par un directeur nommé par un décret
adopté en conseil des Ministres.
Le Collège des enseignants regroupant tous les enseignants-chercheurs de l’Ecole est
chargé de résoudre les problèmes liés à l’organisation pédagogique des enseignements
ainsi que à l’élaboration des emplois du temps.
Le Conseil Scientifique propose les orientations pédagogiques et scientifiques de
l’établissement, en tenant compte notamment de l’évolution du marché de travail et de
l’adéquation des formations dispensées par rapport aux besoins des entreprises.
La figure 1 présente l’organigramme actuel de l’Ecole.

Conseil d'école

Conseil d'école
Conseil Direction
Collège des enseignants
Scientifique
Conseil Direction
Secrétariat Service
Scientifique Principal Pédagogique
Secrétariat Service
Principal Pédagogique
Parcours : Génie Logiciel et Base de
Service de scolarité
Données
Parcours : Génie Logiciel et Base de
Service de scolarité
Données
Parcours : Administration des
Service de comptabilité
Systèmes et Réseaux
Parcours : Administration des
Service de comptabilité
Systèmes et Réseaux
Service intendance Parcours : Informatique Générale
5
Service intendance Parcours : Informatique Générale

Figure 1. Organigramme de l'Ecole Nationale d'Informatique

 Sur cet organigramme, l’Ecole placée sous la tutelle académique et administrative
de l’Université de Fianarantsoa, et dirigée par un Directeur élu par les Enseignants –
Chercheurs permanents de l’Etablissement et nommé par un décret pris en Conseil des
ministres pour un mandat de 3 ans.

Le Conseil de l’Ecole est l’organe délibérant de l’Ecole.

Le Collège des Enseignants propose et coordonne les programmes d’activités pédagogiques.
Le Conseil scientifique coordonne les programmes de recherche à mettre en œuvre à l’Ecole.
Le Secrétariat principal coordonne les activités des services administratifs (Scolarité,
Comptabilité, et Intendance).

Conformément aux textes en vigueur régissant les Etablissements malgaches

d’Enseignement Supérieur, qui sont basés sur le système LMD, les Départements de
Formation pédagogique ont été ainsi remplacés par des Mentions et des parcours. Et les
chefs des Départements ont été ainsi remplacés par des responsables des mentions et les
responsables des parcours.
Un administrateur des Réseaux et Systèmes gère le système d’information de l’Ecole et
celui de l’Université.

1.4. Domaine de spécialisation

Les activités de formation et de recherche organisées à l’ENI portent sur les domaines
suivants :
• Génie logiciel et Base de Données ;
• Administration des Systèmes et Réseaux ;
• Informatique Générale
• Modélisation informatique et mathématique des Systèmes complexes.
D’une manière plus générale, les programmes des formations sont basés sur
l’informatique de gestion et sur l’informatique des Systèmes et Réseaux. Et les modules
de formation intègrent aussi bien des éléments d’Informatique fondamentale que des
éléments d’Informatique appliquée.

6
 Tableau 1.Organisation du système de formation pédagogique de l’Ecole

Formation théorique Formation pratique

- Enseignement théorique - Etude de cas

- Travaux dirigés - Travaux de réalisation
- Travaux pratiques - Projets / Projets tutorés
- Voyage d’études
- Stages

1.5. Architecture des formations pédagogiques

Le recrutement des étudiants à l’ENI se fait uniquement par voie de concours d’envergure
nationale en première année.
Les offres de formation organisées à l’Ecole ont été validées par la Commission
Nationale d’Habilitation (CNH) auprès du Ministères de l’Enseignement Supérieur et de
la Recherche Scientifique selon les dispositions de l’Arrêté N°31.174/2012-MENS en
date du 05 Décembre 2012.
Au sein de l’ENI, il existe une seule mention (INFORMATIQUE) et trois
parcours :
o Génie logiciel et Base de Données ;
o Administration des Systèmes et Réseaux ;
o Informatique Générale
L’architecture des études à trois niveaux conforment au système Licence- Master-
Doctorat (LMD) permet les comparaisons et les équivalences académiques des diplômes
au niveau international.
• L = Licence (Bac + 3) = L1, L2, L3 = 6 semestres S1 à S6
• M = Master (Bac + 5) = M1, M2 = 4 semestres S7 à S10
Le diplôme de licence est obtenu en 3 années des études après Baccalauréat. Et le
diplôme de Master est obtenu en 2 ans après obtenu du diplôme de LICENCE.
Le MASTER PROFESSIONNEL est un diplôme destiné à la recherche emploi au
terme des études.
Le MASTER RECHERCHE est un diplôme qui remplace l’ancien Diplôme
d’Etudes Approfondies (DEA), et qui permet de s’inscrire directement dans une
Ecole Doctorale.au terme des études.

7
 • D = Doctorat (Bac +8)
Le Doctorat est un diplôme qu’on peut obtenir en 3 ans après l’obtention du diplôme
de
MASTER RECHERCHE.
La licence peut avoir une vocation générale ou professionnelle.
Le master peut avoir une vocation professionnelle ou de recherche.

Tableau 2. Liste des formations existantes à l’ENI

FORMATION EN

LICENCE PROFESSIONNELLE MASTER

Condition Par voie de concours

d’admissio
n
Condition Bac de série C, D ou Technique Etre titulaire de licence
d’accès professionnelle
Durée de 3 années 2 années
formation
Diplôme à Diplôme de Licence Diplôme de Master
délivrer Professionnelle en Informatique Professionnel

Diplôme de Master
Recherche

L’accès en première année de MASTER se fait automatiquement pour les étudiants de

l’Ecole qui ont obtenu le diplôme de Licence Professionnelle.
Le Master Recherche permet à son titulaire de poursuivre directement des études en
doctorat et de s’inscrire directement dans une Ecole Doctorale.
Les Ecoles Doctorales jouissent d’une autonomie de gestion par rapport aux Etablissements
de formation universitaire.
Il convient de signaler que par arrêté ministériel N° 21.626/2012 – MESupRES publié le
9 Août 2012 par la Commission National d’habilitation (CNH), l’Ecole Doctorale «
Modélisation – Informatique » a été habilitée pour l’Université de Fianarantsoa.

8
 Depuis l’année universitaire 2010-2011, l’ENI s’est mise à organiser des
formations hybrides en informatique dans les différentes régions (Fianarantsoa, Toliara)
en raison de l’insuffisance de la capacité d’accueil des infrastructures logistiques. En
effet, le système de formation hybride semi - présentielle utilise la visioconférence pour la
formation à distance.
Bien qu’il n’existe pas encore au niveau international de reconnaissance écrite et formelle
des diplômes délivrés par l’ENI, les étudiants diplômés de l’Ecole sont plutôt bien
accueillis dans les instituts universitaires étrangères (CANADA, Suisse, France…)

1.6. Relations de l’ENI avec les entreprises et les organismes

Les stages effectués chaque année par les étudiants mettent l’Ecole en rapport
permanent avec plus de 300 entreprises et organismes publics, semi-publics et privés,
nationaux et internationaux.
L’Ecole dispose ainsi d’un réseau d’entreprises, de sociétés et d’organismes publics et
privés qui sont des partenaires par l’accueil en stage de ses étudiants, et éventuellement
pour le recrutement après l’obtention des diplômes par ces derniers.
Les compétences que l’Ecole cherche à développer chez ses étudiants sont l’adaptabilité,
le sens de la responsabilité, du travail en équipe, le goût de l’expérimentation et
l’innovation.
En effet, la vocation de l’ENI est de former des techniciens supérieurs de niveau
LICENCE et des ingénieurs de type généraliste de niveau MASTER avec des qualités
scientifiques, techniques et humaines reconnues, capables d’évoluer professionnellement
dans des secteurs d’activité variés intégrant l’informatique.
Les stages en milieu professionnel permettent de favoriser une meilleure adéquation entre les
formations à l’Ecole et les besoins évolutifs du marché de l’emploi.
Les principaux débouchés professionnels des diplômés de l’Ecole concernent les
domaines suivants :
✔ L’informatique de gestion d’entreprise
✔ Les technologies de l’information et de la communication (TIC)
✔ La sécurité informatique des réseaux
✔ L’administration des réseaux et des systèmes
✔ Les services bancaires et financiers, notamment le Mobile Banking
✔ Les télécommunications et la téléphonie mobile
✔ Les Big Data

9
 ✔ Le commerce, la vente et l’achat, le Marketing
✔ L’ingénierie informatique appliquée
✔ L’écologie et le développement durable Parmi les sociétés, entreprises et organismes
partenaires de l’Ecole, on peut citer : ACCENTURE Mauritius, Air Madagascar,
Ambre Associates, Airtel, Agence Universitaire de la Francophonie (AUF), B2B,
Banque Centrale, BFG-SG, BIANCO, BLUELINE, CNaPS, Bureau National de
Gestion des Risques et des Catastrophes (BNGRC), CEDII-Fianarantsoa,
Data Consulting, Central Test, Centre National Antiacridien, CNRE, CHU, CNRIT,
COLAS, Direction Générale des Douanes, DLC, DTS/Moov, FID, FTM, GNOSYS,
IBONIA, INGENOSIA, INSTAT, IOGA, JIRAMA, JOUVE, MADADEV, MAEP,
MEF, MEN, MESupRES, MFB, MIC, MNINTER, Min des postes/Télécommunications
et du Développement Numérique, NEOV MAD, Ny Havana, Madagascar National Parks,
OMNITEC, ORANGE, OTME, PRACCESS, QMM Fort-Dauphin, SMMC, SNEDADRS
Antsirabe, Sénat, Société d’Exploitation du Port de Toamasina (SEPT), SOFTWELL,
Strategy Consulting, TELMA, VIVETEC, Société LAZAN’I BETSILEO, WWF …
L’organisation de stage en entreprise continue non seulement à renforcer la
professionnalisation des formations dispensées, mais elle continue surtout à accroître de
façon exceptionnelle les opportunités d’embauche pour les diplômés de l’Ecole.

1.7. Partenariat au niveau international

Entre 1996 et 1999, l’ENI avait bénéficié de l’assistance technique et financière de la

Mission Française de Coopération et d’action culturelle dans le cadre du Programme de
Renforcement de l’Enseignement Supérieur (PRESUP) consacré à l’Ecole a notamment
porté sur :
• Une dotation en logiciels, micro-ordinateurs, équipements de laboratoire de
maintenance et de matériels didactiques
• La réactualisation des programmes de formation assortie du renouvellement du fonds
de la bibliothèque
• L’appui à la formation des formateurs
• L’affectation à l’Ecole d’Assistants techniques français
De 2000 à 2004, l’ENI avait fait partie des membres du bureau de la Conférence
Internationale des Ecoles de formation d’Ingénieurs et Technicien d’Expression
Française (CITEF).

10
 Les Enseignants-Chercheurs de l’Ecole participent régulièrement aux activités organisées
dans le cadre du Colloque Africain sur la Recherche en Informatique (CARI).
L’ENI avait également signé un accord de coopération interuniversitaire avec l’Institut
de Recherche en Mathématiques et Informatique Appliquées (IREMIA) de l’Université
de la Réunion, l’Université de Rennes 1, l’INSA de Rennes, l’Institut National
Polytechnique de Grenoble (INPG).
A partir du mois de Juillet 2001, l’ENI avait abrité le Centre de Réseau Opérationnel
(Network Operating Center) du point d’accès à Internet de l’Ecole ainsi que de
l’Université de Fianarantsoa. Grâce à ce projet américain qui a été financé par l’USAID
Madagascar, l’ENI de l’Université de Fianarantsoa avait été dotées d’une ligne
spécialisée d’accès permanent au réseau Internet.
L’ENI avait de même noué des relations de coopération avec l’Institut de Recherche pour le
Développement (IRD).
L’objet du projet de coopération avait porté sur la modélisation environnementale du
Corridor forestier de Fandriana jusqu’à Vondrozo (COFAV). Dans ce cadre, un atelier
scientifique international avait été organisé à l’ENI en Septembre 2008. Cet atelier
scientifique avait eu pour thème de modélisation des paysages.
Et dans le cadre du programme scientifique PARRUR, l’IRD avait financé depuis 2010
le projet intitulé « Forêts, Parcs et Pauvreté dans le Sud de Madagascar (FPPSM). Des
étudiants en DEA et des Doctorants issus de l’ENI avaient participé à ce Programme.
Par ailleurs, depuis toujours la même année 2010, l’ENI de Fianarantsoa avait été
sélectionnée pour faire partie des organismes partenaires de l’Université de Savoie dans
le cadre du projet TICEVAL relatif à la certification des compétences en TIC ;
Le projet TICEVAL avait été financé par le Fonds Francophone des Inforoutes pour la
période allant de 2010 à 2012, et il avait eu pour objectif de généraliser la certification
des compétences en Informatique et Internet du type C2i2e et C2imi.
Dans le cadre du projet TICEVAL, une convention de coopération avec l’Université de
Savoie avait été signée par les deux parties concernées. La mise en œuvre de la
Convention de Coopération avait permis d’envoyer des étudiants de l’ENI à Chambéry
pour poursuivre des études supérieures en Informatique.
Enfin et non des moindres, l’ENI avait signé en Septembre 2009 un protocole de
collaboration scientifique avec l’ESIROI – STIM de l’Université de la Réunion.

11
Comme l’ENI constitue une pépinière incubatrice de technologie de pointe, d’emplois et
d’entreprises, elle peut très bien servir d’instrument efficace pour renforcer la croissance
économique du pays, et pour lutter contre la Pauvreté.
De même que le statut de l’Ecole devrait permettre de renforcer la position
concurrentielle de la Grande Ile sir l’orbite de la modélisation grâce au développement
des nouvelles technologies.

1.8. Débouchés professionnels avec des diplômés

Le chômage des jeunes diplômés universitaires fait partie des maux qui gangrènent
Madagascar. L’environnement socio-politique du pays depuis 2008 jusqu’ à ce jour a fait que
le chômage des diplômés est devenu massif par rapport aux établissements de formation
supérieure existants.
Cependant, les formations proposées par l’Ecole permettent aux diplômés d’être
immédiatement opérationnels sur le marché du travail avec la connaissance d’un métier
complet lié à l’informatique aux TIC.
L’Ecole apporte à ses étudiants un savoir-faire et un savoir-être qui les accompagnent tout au
long de leur vie professionnelle. Elle a une vocation professionnalisante.
Les diplômés en LICENCE et en MASTER issus de l’ENI peuvent faire carrière dans
différents secteurs.
L’Ecole bénéficie aujourd’hui de 34 années d’expériences pédagogiques et de
reconnaissance auprès des sociétés, des entreprises et des organismes. C’est une Ecole
Supérieure de référence en matière informatique.
Par conséquent, en raison de fait que l’équipe pédagogique de l’Ecole est
expérimentée, les enseignants-chercheurs et les autres formateurs de l’Ecole sont dotés
d’une grande expérience dans l’enseignement et dans le milieu professionnel.
L’Ecole est fière de collaborer de façon régulière avec un nombre croissant
d’entreprises, de sociétés et d’organismes publics et privés à travers les stages des
étudiants. Les formations dispensées à l’Ecole sont ainsi orientées vers le besoin et les
attentes des entreprises et des sociétés.
L’Ecole fournit à ses étudiants de niveau LICENCE et MASTER des compétences
professionnelles et métiers indispensables pour les intégrer sur le marché du travail.
L’Ecole s’efforce de proposer à ses étudiants une double compétence à la fois
technologique et managériale combinant l’informatique de gestion ainsi que
l’administration des réseaux et systèmes.

12
 D’une manière générale, les diplômés de l’ENI n’éprouvent pas de difficultés
particulières à être recrutés au terme de leurs études. Cependant, l’ENI recommande à ses
diplômés de promouvoir l’entrepreneuriat en TIC et de créer des cybercafés, des SSII ou
des bureaux d’études.
Tableau 3. Débouchés professionnels éventuels des diplômés

LICENCE - Analyste

- Programmeur

- Administrateur de site web/de portail web

- Assistant Informatique et internet

- Chef de projet web ou multimédia

- Développeur Informatique ou multimédia

- Intégrateur web ou web designer

- Hot liner/Hébergeur Internet

- Agent de référencement

- Technicien/Supérieur de help desk sur Informatique

- Responsable de sécurité web

- Administrateur de réseau

MASTER - Administrateur de réseau et système

- Architecture de système d’information

- Développeur d’applications

- Ingénieur réseau

- Webmaster /web designer

- Concepteur Réalisateur d’applications

- Directeur du système de formation q

13
 - Directeur de projet informatique

- Chef de projet informatique

- Responsable de sécurité informatique

- Consultant fonctionnel ou freelance

1.9. Ressources humaines

• Directeur de l’Ecole : Docteur MAHATODY Thomas, Docteur HDR

• Responsable de Mention : Monsieur RABETAFIKA Louis Haja, Maître de
Conférences
• Responsable de Parcours « Génie Logiciel et Base de Données » : Monsieur
RALAIVAO Jean Christian, Assistant d’Enseignement Supérieur et de Recherche
• Responsable de Parcours « Administration Systèmes et Réseaux » : Monsieur SIAKA,
Assistant d’Enseignement Supérieur et de Recherche
• Responsable de Parcours « Informatique Générale » : Monsieur GILANTE Gesazafy,
Assistant d’Enseignement Supérieur et de Recherche
• Nombre d’Enseignants permanents : 12 dont un (01) Professeur Titulaire, deux (02)
Professeurs, cinq (05) Maîtres de Conférences et quatre (04) Assistants
d’Enseignement Supérieur et de Recherche
• Nombre d’Enseignants vacataires : 10
Personnel Administratif : 23

14
 CHAPITRE 2 : PRESENTATION DE LA SOCIETE RELIA
CONSULTING

Dans ce chapitre, nous allons voir la présentation et les activités de l’entreprise où

s’est déroulé le stage.

2.1 Présentation et historique

RELIA est une entreprise de service numérique spécialisée dans le développement

web, mobile et logiciel sur mesure.

Relia visionne de devenir une ESN de référence à Madagascar en vivant dans la valeur
de partage, proximité et excellence au sein de son équipe en interne ainsi que ses clients et
partenaires.

Chez RELIA nous travaillons avec des clients locaux ainsi que des clients partout dans
le monde. Parmi ses visions, relia envisage de divulguer la technologie dans tous les domaines
à Madagascar comme l’Education, la santé, le commerce, le transport, l’hôtellerie et
tourisme... etc.

Si jeune qu’elle soit, née en 2020, RELIA a connu une forte croissance dû à ses succès
auprès des clients et les valeurs partagés en interne avec ses collaborateurs. La société compte
actuellement une trentaine de collaborateurs .

2.2. Situation géographique de RELIA

RELIA se situe à Ambohimiandra, Antananarivo Madagascar. Elle est limitée, au Sud

par Ambanidia, au Nord-Est par Mandroseza et au Nord-Ouest par Mahazoarivo.

15
 Figure 2. Localisation de RELIA

2.3 Missions de RELIA

Relia a pour but de :

- Apporter de nouvelles technologies dans tous les domaines à Madagascar d’ici 5 ans
- Se développer au niveau international pour pérenniser l’entreprise
- Créer des sites web, applications et logiciels selon les demandes existantes

2.4 Organisation et fonctionnement de RELIA

RELIA est une entreprise en phase de startup. Néanmoins, elle est déjà composée de plusieurs
équipes de développeurs expérimentés, et suit la méthodologie AGILE pour gérer les projets.

Elle fonctionne en suivant les principes suivants :

 Les individus et les interactions, plus que les outils et les processus ;

 Des logiciels opérationnels, plus qu’une documentation exhaustive ;

16
  La collaboration avec le client, plus que la négociation contractuelle ;

 L’adaptation au changement, plus que le suivi d’un plan ;

Ces principes mettent en avant la valeur du produit délivré au client, ainsi que la relation.

Il existe des animateurs et qui facilitent la communication avec le client, et qui sont
chargés de résoudre les problèmes de compréhension entre les deux entités. De courtes
réunions se font régulièrement pour valider les avancées et communiques la progression du
projet selon des termes acceptables.

Les rôles sont repartis pour assurer le bon fonctionnement de l’entreprise, et des
projets qu’elle reçoit. Il y a les responsables de la compréhension, de l’adhésion et de la mise
en œuvre de la méthode appropriée applicable aux divers projets. Ils veillent à ce que les
principes et les valeurs de la méthode suivie soient respectés. Ils facilitent la communication
au sein de l’équipe et cherchent à maximise la productivité.

Les propriétaires de projets qui portent la vision du produit à réaliser. Ils travaillent en
interaction avec l’équipe de développement qui doit suivre leurs instructions. C’est eux qui
établissent la priorité des fonctionnalités à développer ou à corriger, et qui valident les
fonctionnalités terminées.

Les équipes de développement qui se chargent de réaliser les demandes exprimées par
les propriétaires de projets.

2.5 Organigramme

Bien que RELIA soit encore une entreprise en phase de startup, elle est déjà dotée de
plusieurs équipes de développeurs expérimentés. La figure 3 nous illustre l’organigramme de
RELIA

17
 Figure 3. Organigramme de RELIA

CEO : Chief Executive Officer

CTO : Chief Technology Officer
BD Manager: Business Development Manager
CM: Community Manager
CHO: Chief Human Officer
CPO: Chief Product Officer
CFO: Chief Financial Officer

18
 CHAPITRE 3 : DESCRIPTION DU PROJET
La description du projet implique la définition des objectifs, la description des activités
à réaliser, le choix des techniques à mettre en œuvre ainsi que les résultats attendus.

3.1 Formulation

De nos jours, les services de livraison sont de plus en plus fréquents et demandés par
les consommateurs. Autrefois facultatif, les livraisons sont désormais indispensables pour tout
type de commerce.

Comme tout site e-commerce, il est nécessaire de proposer un service de livraison, il

s’agit du principal point de contact entre le site vendeur et l’acheteur, la livraison constitue
une part importante de l’expérience client.

De ce fait, l’entreprise souhaite mettre en place un site e-commerce où des personnes

pourront s’inscrire en tant que livreurs. Ainsi, le projet consiste à la conception et à la
réalisation d’un module de livraison.

A noter que ce projet suit une architecture de microservices, c’est-à-dire que chaque
module du site est conçu indépendamment des autres.

3.2 Objectif et besoins de l’utilisateur

Ce projet a pour but de concevoir et de réaliser une application permettant d’effectuer

des livraisons des achats des clients sur le site. Pour ce faire, une analyse sur l’optimisation
des services de livraisons actuelles et aussi du déroulement des étapes d’une livraison ont été
effectué.

D’autre part, l’application a été conçue depuis un design Mobile First car dans la
logique, les téléphones portables seront plus adaptés pour les livreurs

Ainsi, l’application devra mettre à disposition divers fonctionnalités, les utilisateurs

pourront :

- S’inscrire en tant que livreur particulier ou en tant qu’entreprise ou société de

livraison,
- Voir les différentes offres d’inscription,
- Modifier et consulter leur profil,
- Consulter les livraisons proches de sa position, ou sur le trajet du livreur,
19
 - Consulter les offres de livraison par les acheteurs.
- Avoir un tableau de bord sur les livraisons en cours et les livraisons à venir.

3.3 Moyens nécessaires à la réalisation du projet

Afin de mener à terme ce projet, l’existence des différents moyens tels qu’humains,
matériels seront nécessaires. Le tableau 4 nous donne le résumé de ces différentes nécessités.

Tableau 4. Moyens nécessaires à la réalisation du projet

Moyens Caractéristiques
Humains - Développeur et concepteur : stagiaire
- Chef de projet : encadreur professionnelle
Matériels - Ordinateurs : pour élaborer l’application
- Connexion internet : pour se documenter et faire des
recherches
Logiciels - IDE : Visual Studio (pour développer l’application)
- SGBD : MongoDB (Pour stocker les données et
interagir avec l’utilisateur)
- Web mail : Skype (pour faciliter la communication)
Méthode de conception UML : Pour analyser conceptuellement le projet
et de gestion de projet
informatique

Le tableau 5 montre les caractéristiques de l’ordinateur utilisé.

Tableau 5. Caractéristiques des ordinateurs utilisés

MARQUE CPU MEMOIRE DISQUE DUR

MSI Core i5 @2.50Ghz 8go SSD 500Go

20
3.4 Résultats attendus

A la fin de ce projet, on attend à obtenir une application web sécurisée, performante,

réutilisable, une application qui suit les normes de qualité d’un logiciel ; Et surtout une
application qui intègre les fonctionnalités demandées.

3.5 Chronogramme

Un chronogramme, aussi appelé diagramme temporel, est un graphique qui met

visuellement en perspective les tâches à accomplir par rapport à une chronologie déterminée.

La figure 4 nous montre le chronogramme d’activité.

Figure 4. Chronogramme d’activité

21
PARTIE II : ANALYSE ET CONCEPTION

22
 CHAPITRE 4 : ANALYSE PREALABLE

Ce chapitre consiste principalement à recenser l’existant, c’est-à-dire les solutions

informatiques déjà mises en œuvre sur le marché et à recenser les besoins notamment en
termes de fonctionnalités nouvelles.

4.1 Analyse de l’existant

4.1.1 Organisation actuelle

Dans le monde du numérique actuel, les livraisons sur les sites e-commerce se font
généralement par un personnel du site elle-même. Le client peut choisir l’option de livraison
qui lui convient le mieux lors de sa commande en ligne. Une fois que la commande est passée
et effectuée, le transporteur est chargé de livrer le colis au client à l’adresse indiquée.

4.1.2 Inventaire des moyens matériels et logiciels

Pour les consommateurs sur les sites e-commerce, énumérons leurs moyens d’accès à
ces plateformes.

 Moyens matériels :
o Les ordinateurs
o Les téléphones portables
 Moyens logiciels :
o Navigateurs internet : Chrome, Firefox, …

4.2 Critique de l’existant

Après avoir analysé les organisations actuelles, nous allons définir les points forts et
les points faibles de ce système déjà existant dans le Tableau 6.

23
 Tableau 6. Points faibles et points forts du système existant

Points forts Points faibles

 Eviter les tracas et les files d’attente
dans les magasins physiques.
 Confiance donnée au site elle-même
 Obtention d’une date de livraison
 Les livraisons sur les certains sites
peuvent prendre plus de temps que
prévu.
 Certaines adresses peuvent être
obsolètes.
 Aucun site à Madagascar ne propose
aux utilisateurs de devenir livreur
 Date de livraison parfois non
respectée

4.3 Conception de l’avant-projet

La conception de l’avant-projet consiste à définir la faisabilité, identifier les

principaux risques et baser la décision de lancement de projet.

4.3.1 Proposition de solutions

Pour pallier à ces problèmes, on a envisagé la mise en place d’une application facile à
utiliser, incluant les fonctionnalités basiques des livraisons sur un site e-commerce, et les
autres fonctionnalités pouvant apporter des solutions.

Le Tableau 7 représente les solutions possibles pouvant remédier aux différentes

lacunes soulevées.

Tableau 7. Tableau de comparaison des solutions proposées

Solutions  Avantages Inconvénients

Achat d’une application - Prêt à employer - Payant (ex : Module
(ex : Prestashop) - Contient des Prestashop 160$)
fonctionnalités utiles - Manque de fonctionnalités
répondant aux besoins

24

Réalisation d’une - Personnalisable
application - Possibilité d’évolution de
l’application dans de le
temps
spécifiques
- Coût de maintenance élevé
- Mise en œuvre nécessitant
beaucoup de moyens et de
temps

L’entreprise a opté pour la conception d’une application web permettant aux

utilisateurs de s’inscrire en tant que livreur, avec une interface simple et facile à utiliser.

4.3.2 Méthode de gestion de projet utilisée

La gestion de projet est l’ensemble des activités et des techniques utilisées pour
planifier, organiser, diriger et contrôler les ressources d’un projet afin d’atteindre les objectifs
fixés.

Parmi les différentes méthodes de gestion de projet, les plus populaires et efficaces
selon le projet sont :

 Approche traditionnelle :
Cette approche est un modèle de développement de logiciels qui met l’accent sur la
planification détaillée et la prévision à l’avance du processus de développement.
L’approche traditionnelle peut être utile pour les projets de grande envergure et
complexes, mais peut également être rigide et peu adaptable aux changements au fur
et à mesure que le projet avance.
 Approche Agile :
Cette approche est un modèle de développement de logiciels qui met l’accent sur la
flexibilité et l’adaptation aux changements, plutôt que sur la planification détaillée à
l’avance. Les équipes qui utilisent la méthode Agile peuvent rapidement réagir aux
changements de direction et aux nouvelles exigences, ce qui peut aider à créer des
logiciels de haute qualité qui répondent aux besoins réels des utilisateurs.

25
 Dans la figure 5, nous avons la comparaison entre l’approche traditionnelle et
l’approche Agile. [9]

Figure 5. Comparaison approche traditionnelle et approche Agile

26
Pour avoir une meilleure flexibilité, nous avons choisi d’utiliser la méthode Agile. Elle
permettra aussi d’adapter rapidement le travail en fonction des changements ou des imprévus.

a- Choix de la méthode Agile à utiliser

Il existe plusieurs variantes de la méthode Agile, chacune ayant ses propres

caractéristiques et avantages. De ce fait, le choix de la méthode agile à utiliser dépendra des
besoins et des objectifs du projet en question.

Voici les valeurs fondamentales du manifeste Agile :

- Les individus et leurs interactions plutôt que les processus et les outils.
- Le travail produit plutôt que les documents de gestion.
- La collaboration avec les clients plutôt que la négociation contractuelle.
- La réponse aux changements plutôt que le suivi d’un plan.

Dans le tableau 8, nous pouvons voir la comparaison entre quelques méthodes agiles.

Tableau 8. Comparaison méthode Agile

Nom Avantages Désavantages

SCRUM - Meilleure gestion du projet
et gestion de temps grâce
aux sprints.
KANBAN - Permet de suivre les tâches
et les projets en temps réels,
meilleure gestion des
priorités et des ressources
SCRUMBAN - Conserve l’approche de
SCRUM
- Itération limitée évitant la
surproduction
- Nécessite une organisation
rigoureuse et une bonne
communication au sein des
équipes
- S’adresse principalement à
une production répétitive
-Absence d’attribution de
rôles et d’organisation de
meetings

Dans le cadre de ce projet, nous avons choisi la méthode SCRUM pour une excellente
communication entre les différents acteurs du projet grâce au Daily Scrum Meeting.

27
 b- Présentation de SCRUM

Elle offre une meilleure flexibilité et une plus grande efficacité dans la réalisation du
projet. Elle s’appuie sur des équipes autonomes et collaboratives, des réunions fréquentes et
des objectifs pour chaque sprint.

Une équipe Scrum est généralement composée de trois types de membre : Le Product
Owner qui est responsable de la définition des fonctionnalités et des priorités, le Scrum
Master qui veille à ce que la méthode Scrum soit correctement appliquée, et les développeurs
qui sont chargées de mettre en œuvre les fonctionnalités définies par le product owner.

Dans le cas de notre projet :

- Product Owner : RAHARISON Francesca ;

- Scrum master : RAZANAMIHOATRA Jean Christian ;
- Membres de l’équipe de développement :
o RAKOTOSON Aina Nirina
o RANOELISON Nomena
o MIALINIRINA Daniela

La figure 6 nous montre le processus de la méthode Scrum [10]

Figure 6. Processus de la méthode SCRUM

28
 - Le carnet de produit ou Product Backlog est la liste des éléments, des fonctionnalités
ou des tâches importants du projet.

- Durant le planning meeting, avant de commencer un sprint, l’équipe de

développement se réunit pour déterminer les objectifs et les tâches qui seront abordés durant
le sprint.

- A la fin du sprint, l’équipe de développement présente les fonctionnalités terminées

au cours de celui-ci et recueil les feedbacks du Product Owner et des utilisateurs. C’est
également le moment d’anticiper le périmètre des prochains sprints et d’ajuster au besoin la
planification de release (nombre de sprints restants).

Le planning prévu au début du stage :

 03 Octobre-16 Octobre 2022 : Sprint 0, analyse des besoins et conception de

l’application.
 17 Octobre-23 Octobre 2022 : Mise en place des environnements de développement.
 24 Octobre-26 Octobre 2022: Sprint planning meeting.
 27 Octobre-13 Novembre 2022 : Réalisation du sprint 1.
 14 Novembre-15 Novembre 2022 : Rétrospective des points positifs et négatifs du
premier Sprint – Sprint planning 2.
 16 Novembre 2022-29 Novembre 2022 : Réalisation du sprint 2.
 30 Novembre-01 Décembre 2022 : Sprint Review – Rétrospective – Sprint Planning
meeting ;
 02 Décembre – 15 Décembre 2022 : Réalisation du sprint 3.
 16 Décembre – 17 Décembre 2022 : Sprint Review – Rétrospective.

4.3.3 Méthodes et outils utilisés

4.3.3.1 Utilisation de la méthode 2TUP (Two Tracks Unified Process)

Le tableau 9 présente la comparaison entre MERISE et 2TUP.

29
 Tableau 9. Comparaison de la méthode 2TUP et MERISE

Méthodes Points forts Points faibles

2TUP - Itératif et incrémental - Nécessite un apprentissage
- Processus orienté objet - Superficiel sur les phases
- Description dynamique du système situées en ascendant du
développement : capture des
besoins, support,
maintenance
MERISE - Méthode orientée fonction - Ne s’occupe pas de
- Structuration en étape et en point de l’interface utilisateur
contrôle
- Approche conceptuelle, se focalisant sur
les métiers et les besoins associés.

Prenant en considération la durée de stage et l’évolution du système, il est

indispensable d’utiliser la méthode 2TUP. De plus, c’est un processus qui implémente le
processus unifié (méthode de développement pour les logiciels orientés objets et complète la
systématique des modèles UML).

4.3.3.2 Utilisation du langage de modélisation UML (Unified Modeling

Language)

Pour tout projet informatique, la conception d’un système de formation nécessite une
méthode de conception, dans notre cas, nous avons choisi UML, qui est un langage de
modélisation orientée objet.

UML est un langage de modélisation standardisé énormément utilisé, il permet de

présenter de manière visuelle les différents aspects d’un système grâce à ses différents
diagrammes. UML peut être également utilisé pour documenter les différents aspects d’un
système de manière claire et concise, ce qui peut être utile pour la communication et la
gestion de projet. UML peut aussi être aussi utiliser pour générer du code à partir des
modèles, ce qui peut accélérer le développement et réduire les erreurs de code.

30
 4.3.3.3 Choix du langage de programmation

Un langage de programmation est une notation conventionnelle destinée à formuler

des algorithmes et produire des programmes informatiques qui les appliquent. D'une manière
similaire à une langue naturelle, un langage de programmation est composé d'un alphabet,
d'un vocabulaire, de règles de grammaire, de significations, mais aussi d'un environnement de
traduction censé rendre sa syntaxe compréhensible par la machine [4].

Pour nous aider avec le choix de langage de programmation, le tableau 10 nous montre
une comparaison de quelques langages de programmation orienté web.

Tableau 10. Comparaison PHP et NodeJs

PHP Javascript (NodeJs)

Avantages - Simple et facile à apprendre
- Intégré à de nombreux CMS tels
que Wordpress, Drupal,…
- Langage de programmation
mature, utilisé depuis des années.
- Compatible avec la plupart des
systèmes d’exploitation et des
serveurs web, facile à déployer.
Inconvénients - Syntaxe parfois difficile à
comprendre
- Moins performant que d’autres
langages de programmation côté
serveur.
- Peut avoir des problèmes de
sécurité si les pratiques de
développement adéquates ne sont
pas suivies.
- Basé sur Javascript, qui est un
langage populaire et très utilisé.
- Conçu pour les applications en
temps réel
- Capable de gérer de nombreuses
connections simultanées, plus
adapté pour les applications qui
nécessitent une grande quantité de
données en temps réel.
- Compatible avec la plupart des
systèmes d’exploitation et des
serveurs web, facile à déployer.
- Relativement récent et peut
manquer de maturité et de
documentations.
- Peut être sujet à des problèmes de
mémoire si les pratiques de
développement adéquates ne sont
pas suivies.

31
 - Moins adapté pour le
développement d’application en
temps réel.

Vis-à-vis de ces comparaisons, nous avons opté pour NodeJs.

4.3.3.4 Framework de développement

En programmation informatique, un Framework est un kit de composants logiciels

structurels, qui définit les fondations et les grandes lignes de l 'organisation de tout ou partie
d'un logiciel (architecture). Autrement dit, un framework Javascript est un ensemble de codes
qui fournit une organisation ainsi qu'un grand nombre de fonctionnalités, dont le nombre et la
qualité diffèrent selon les Frameworks [2].

Le tableau 11 et 12 représente une comparaison des frameworks Javascript et NodeJs

les plus populaires :

Tableau 11. Comparaison entre VueJs, ReactJs et Angular

Framework Avantages Inconvénients

VueJs - Prise en main facile - Framework récent
- Simple -Communauté restreinte
ReactJs - Compatible avec de nombreux - Utilisation de la syntaxe JSX qui
outils et bibliothèques tiers peut être difficile à maîtriser
- Très populaire, très grande - Nécessite l’installation de module
communauté tiers pour certaines fonctionnalités
de base.
Angular - Structure MVC - Complexe
- Performant - Apprentissage long
- Documentation détaillée

Nous avons opté pour le framework Angular car Angular est un framework très
complet et sa structure MVC est plus facile à gérer.

32
 Tableau 12. Comparaison entre ExpressJs et NestJs

Framework Avantages Inconvénients

ExpressJs - Simple à apprendre et à utiliser - N’offre pas de fonctionnalités de
- Compatible avec de nombreux mise en œuvre de l’IU
modules tiers - Moins adapté pour le
- Soutenu par une communauté développement d’applications en
en croissance et est constamment temps réel.
mis à jour.
NestJs - Offre une architecture - N’offre pas de fonctionnalités de
modulaire qui permet de mieux mise en œuvre de l’IU
décomposer l’application en - Nécessite une certaine courbe
parties plus petites et plus faciles d’apprentissage et peut être difficile
à gérer à comprendre.

Pour ce projet, nous avons opté pour NestJs pour sa structure plus facile à comprendre
et mieux orgarnisée.

4.3.3.5 Utilisation de l’IDE (Integral Development Environment)

Comme environnement de développement, on a choisi Visual Studio Code. VS Code

est gratuit, avec une grande communauté active de développeurs qui participent à l’ajout de
nouvelles extensions. De plus, il est léger et rapide, et est plus optimal pour faire du
Javascript.

4.3.3.6 Utilisation du SGBD

Le tableau 13 représente la comparaison entre les SGBD MySQL et MongoDB.

Tableau 13. Comparaison entre MySQL et MongoDB

SGBD Avantages Inconvénients

MySQL - Gratuit et Open-source - Ne fournit pas certaines
- Facile à utiliser et a une interface fonctionnalités telles que le support
utilisateur conviviale (ex : du format JSON

33
 PhpMyAdmin)
- Bonnes performances et efficace
pour gérer de grandes quantités de
données
MongoDB - Utilise une base de données - Peut être difficile à comprendre si
NoSQL, qui rend idéale pour les on a aucune expérience en NoSQL.
données à schéma flexible - Nécessite une maintenance
- Offre une grande flexibilité dans constante comme l’optimisation des
la modélisation des données index et la gestion de la mémoire

Pour ce projet, on a utilisé MongoDB pour avoir des données flexibles, car les données
et les collections pourront changer au fil du temps dû à cette architecture micro service. De
plus, l’intégration de MongoDB dans NestJS est assez simple et facile à utiliser.

34
 CHAPITRE 5 : ANALYSE CONCEPTUELLE
L’analyse conceptuelle portera sur l’identification des différents utilisateurs, la
description des informations et des fichiers dont ses utilisateurs auront besoin, mais aussi une
nouvelle circulation d’informations favorables pour le nouveau système.

5.1 Dictionnaire des données

Un dictionnaire des données est une collection d’informations, de données nécessaires

à la réalisation de la conception.

Le tableau 14 rapporte le dictionnaire de données établi lors de l’analyse.

Tableau 14. Dictionnaire des données

Rubrique Description Type Taill Observation

e
address_id Identifiant de AN 24
l’adresse
address_formated Adresse formatée AN 40
address_street Rue de l’adresse AN 40
address_locality Localisation AN 40
address_postal_code Code postal AN 12
address_country Pays A 32
buyer_id Identifiant de AN 24
l’acheteur
company_id Identifiant AN 24
compagnie
company_name Nom de la AN 32
compagnie
delivery_man_id Identifiant du AN 24
livreur
dman_transport_type Type de transport A 32
dman_cv_file_path Chemin CV AN 50
dman_residence_certificate_file_pat Chemin Certificat AN 50
h de résidence
dman_transport_id_card_file_path Chemin carte de AN 50

35
 transport
dman_insurance_file_path Chemin assurance AN 50
dman_business_licence_file_path Chemin licence AN 50
commerciale
dman_national_id_card_file_path Chemin CIN AN 50
dman_register_status Status d’inscription AN 12
delivery_id Identifiant livraison AN 24
delivery_begin_location Localistion de AN 50
départ
delivery_ending_location Localisation AN 50
d’arrivée
delivery_man_response Réponse du livreur AN 12
delivery_status_filter Status de la AN 12
livraison
delivery_date Date de livraison Date 10 dd/MM/yyyy
delivery_is_fragile Livraison fragile A 12
delivery_publish_date Date de publication Date 10 dd/MM/yyyy
seller_id Identifiant du AN 24
vendeur
user_id Indentifiant de AN 24
l’utilisateur
user_company Compagnie de AN 50
l’utilisateur
user_name Nom de l’utilisateur AN 50
user_email Email de AN 50
l’utilisateur
user_family_name Nom de famille de AN 50
l’utilisateur
user_phone_number Numéro telephone AN 24
de l’utilisateur
user_region Region de A 40
l’utilisateur
user_phone_number_verified Vérification numéro A 12

36
 de téléphone
user_email_verified Vérifaation email A 12
user_gender Genre de A 12
l’utilisateur
user_birthdate Date de naissance Date 10 dd/MM/yyyy
de l’utilisateur

AN: Alphanumérique

N: Numérique

A: Alphabétique

5.2 Règles de gestion

Une règle de gestion est la traduction conceptuelle des objectifs choisis et des
contraintes acceptées par l’entreprise. Elle est plus particulièrement liée aux traitements (règle
d’action) ou aux données (règle de calcul) :

RG1 : Un utilisateur n’a qu’une et une seule adresse

RG2 : Une adresse peut appartenir à un ou plusieurs utilisateurs

RG3 : Une compagnie se trouve à une adresse

RG4 : Un livreur, un vendeur, un acheteur sont des utilisateurs

RG5 : Un permis n’appartient qu’à un et un seul livreur, et un livreur n’a qu’un seul permis.

RG6 : Un livreur peut effectuer une ou plusieurs livraisons.

RG7 : Une livraison ne peut être effectuée que par un seul livreur

RG8 : Une livraison doit avoir un acheteur et un vendeur

37
 5.3 Représentation et spécification des besoins

5.3.1 Présentation d’UML

Le langage UML (Unified Modeling Language, ou langage de modélisation unifié) a

été pensé pour être un langage de modélisation visuelle commun, et riche sémantiquement et
syntaxiquement. Il est destiné à l'architecture, la conception et la mise en œuvre de systèmes
logiciels complexes par leur structure aussi bien que leur comportement. L'UML a des
applications qui vont au-delà du développement logiciel, notamment pour les flux de
processus dans l'industrie. [6]
Il est donc une norme du langage de modélisation objet qui a été publiée, dans sa
première version, en novembre 1997 par l’OMG (Object Management Group), instance de
normalisation internationale du domaine de l’objet. En quelques années, UML s’est imposée
comme standard à utiliser en tant que langage de modélisation objet [1].

UML, dans sa dernière version, propose treize diagrammes qui peuvent être utilisés
dans la description d’un système. Ces diagrammes sont regroupés dans deux grands
ensembles.

- Les diagrammes structurels : Ces diagrammes, au nombre de six, ont vocation à représenter
l’aspect statique d’un système (classes, objets, composants…).
 Diagramme de classe : Ce diagramme représente la description statique du système en
intégrant dans chaque classe la partie dédiée aux données et celle consacrée aux traitements.
C’est le diagramme pivot de l’ensemble de la modélisation d’un système.
 Diagramme d’objet : Le diagramme d’objet permet la représentation d’instances des classes et
des liens entre instances.
 Diagramme de composant : Ce diagramme représente les différents constituants du logiciel au
niveau de l’implémentation d’un système.
 Diagramme de déploiement : Ce diagramme décrit l’architecture technique d’un système avec
une vue centrée sur la répartition des composants dans la configuration d’exploitation.
 Diagramme de paquetage : Ce diagramme donne une vue d’ensemble du système structuré en
paquetage. Chaque paquetage représente un ensemble homogène d’éléments du système
(classes, composants…).
 Diagramme de structure composite : Ce diagramme permet de décrire la structure interne d’un
ensemble complexe composé par exemple de classes ou d’objets et de composants techniques.
Ce diagramme met aussi l’accent sur les liens entre les sous-ensembles qui collaborent.

38

- Les diagrammes de comportement : Ces diagrammes représentent la partie dynamique d’un
système réagissant aux événements et permettant de produire les résultats attendus par les
utilisateurs. Sept diagrammes sont proposés par UML :
 Diagramme des cas d’utilisation : Ce diagramme est destiné à représenter les besoins des
utilisateurs par rapport au système. Il constitue un des diagrammes les plus structurants dans
l’analyse d’un système.
 Diagramme d’état-transition (machine d’état) : Ce diagramme montre les différents états des
objets en réaction aux événements.
 Diagramme d’activités : Ce diagramme donne une vision des enchaînements des activités
propres à une opération ou à un cas d’utilisation. Il permet aussi de représenter les flots de
contrôle et les flots de données.
 Diagramme de séquence : Ce diagramme permet de décrire les scénarios de chaque cas
d’utilisation en mettant l’accent sur la chronologie des opérations en interaction avec les
objets.
 Diagramme de communication (anciennement appelé collaboration) : Ce diagramme est une
autre représentation des scénarios des cas d’utilisation qui met plus l’accent sur les objets et
les messages échangés.
 Diagramme global d’interaction : Ce diagramme fournit une vue générale des interactions
décrites dans le diagramme de séquence et des flots de contrôle décrits dans le diagramme
d’activités.
 Diagramme de temps : Ce diagramme permet de représenter les états et les interactions
d’objets dans un contexte où le temps a une forte influence sur le comportement du système à
gérer.

5.3.2 Identification des acteurs

Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif
matériel ou autre système) qui interagit directement avec le système étudié.

Tous les éléments extérieurs qui stimulent le système et tous les éléments extérieurs qui sont
utilisés par le système sont représentés par des acteurs. Dans le cas d'acteurs non-humains il
est possible de définir une « Interface » qui représente les opérations offertes par cet acteur.

39
 Dans notre projet on peut discerner deux (2) principaux acteurs : le livreur et
l’utilisateur, et deux (2) acteurs secondaires : l’administrateur et le fournisseur d’identité.

La Figure 7 nous représente un acteur de l’application.

Figure 7. Représentation d’un acteur

5.3.3 Identification des messages

Un message représente la spécification d’une communication unidirectionnelle entre

objets qui transporte de l’information avec l’intention de déclencher une activité chez le
récepteur.

Dans le tableau 15, nous avons des extraits des messages échangés entre un acteur et le
système en tenant compte de l’action qu’un utilisateur peut faire dépend du droit qu’il
possède.

Tableau 15. Extrait des messages échangés

Acteurs Messages
Emis Reçu
Simple utilisateur Demande de consulter les Interface avec les différents
offres offres affichés
Demande d’inscription en Page de création d’un
tant que livreur compte livreur
Livreur Demande de voir les Page avec la liste des
livraisons recommandées livraisons proches
Demande de voir les Page affichant les livraisons
livraisons en cours en cours
Demande de voir les Page affichant les livraisons
livraisons terminées terminées
Demande de voir les Page affichant les offres de

40

Administrateur
Fournisseur d’identité
demandes de livraisons
Demande de consulter les
détails d’une livraison
Demande d’accepter une
livraison
Demande de modifier son
trajet
Demande d’affichage d’une
inscription en cours
Demande de vérification du
compte utilisateur
livraisons par les acheteurs
Page affichant tous les
détails d’une livraison
Bouton permettant
d’accepter une livraison
Interface permettant de
modifier le trajet
Interface permettant de voir
les informations de
l’inscription
Interface de connexion

5.3.4 Diagramme de cas d’utilisation

Un cas d'utilisation, ou cas d'usage (« use-case » en anglais), définit en génie logiciel et

en ingénierie des systèmes une manière d'utiliser un système qui a une valeur ou une utilité
pour les acteurs impliqués. Le cas d'utilisation correspond à un ensemble d'actions réalisées
par le système en interaction avec les acteurs en vue d'une finalité. L'ensemble des cas
d'utilisation permet ainsi de décrire les exigences fonctionnelles d'un système en adoptant le
point de vue et le langage de l'utilisateur final [5].

Le diagramme de cas d’utilisation est composé de :

- Acteur : entité externe qui agit sur le système. Le terme acteur ne désigne pas
seulement les utilisateurs humains mais également les autres systèmes. Les acteurs
sont des classificateurs qui représentent des rôles au travers d'une certaine utilisation
(cas) et non pas des personnes physiques. Ce sont des acteurs types.

- Cas d’utilisation : ensemble d’actions réalisées par le système en réponse à une

action d’un acteur.
 Les cas d’utilisation peuvent être structurés,
 Les cas d’utilisation peuvent être organisés en paquetages,
 L’ensemble des cas d’utilisation décrit les objectifs du système.

41
La figure 8 illustre le diagramme des cas d’utilisations élaboré lors de la conception.

Figure 8. Diagramme de cas d'utilisation

5.3.5 Priorisation des cas d’utilisation

42
 La priorité des cas d’utilisation est conforme aux besoins de l’utilisateur et de la
fonctionnalité de l’application. Ce qui veut dire que ceux qui ont le plus de priorité
garantissent le fonctionnement minimal du logiciel.

Indice 1 : Cas d’utilisation les plus prioritaires.

Indice 2 : Cas d’utilisation prioritaires.

Indice 3 : Cas d’utilisation les moins prioritaires.

Le tableau 16 nous montre la priorisation des cas d’utilisation.

Tableau 16. Priorisation des cas d'utilisation

Nom du cas d’utilisation Priorité

S’inscrire en tant que livreur 1
S’authentifier 1
Voir détails livraison 2
Voir la liste des livraisons 2
Voir la liste des livraisons recommandées 2
Voir la liste des livraisons en cours 2
Voir les demandes de livraison 2
Modifier son trajet 2
Consulter les offres d’inscription 3

5.3.6 Description textuelle de chaque cas d’utilisation

Le diagramme de cas d'utilisation décrit les grandes fonctions d'un système du point de
vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et les cas
d'utilisation. Il est recommandé de rédiger une description textuelle, car c'est une forme
souple qui convient dans bien des situations [3]. Ces définitions servent à fixer les idées lors
de l’identification des cas d’utilisation et n’ont aucun caractère exhaustif.

Nous allons établir la description textuelle des cas d’utilisation « s’inscrire en tant que
livreur » et « voir détails livraison ».

43
 a- Cas d’utilisation « S’inscrire en tant que livreur »

Acteur principal : utilisateur.

Acteur secondaire : aucun.

Préconditions :

- L’utilisateur veut créer un compte livreur

- L’utilisateur accède à l’interface d’inscription

Postconditions :

- L’utilisateur doit avoir un compte en tant que simple utilisateur

Scénario nominal :

1. L’utilisateur rempli les champs demandés.

2. L’utilisateur insère tous les fichiers nécessaires.
3. L’utilisateur accepte les conditions générales d’utilisation de l’application.
4. L’utilisateur envoie le formulaire rempli.
5. Le système vérifie et traite les données.
6. Le système notifie l’employeur pour la confirmation de son dossier.

Scénario alternatif :

4a- Les données envoyées comportent des erreurs.

Le système notifie les erreurs et revient à l’étape 1 du scénario nominal.

b- Cas d’utilisation « Voir détails livraison »

Acteur principal : livreur

Acteur secondaire : aucun

Préconditions :

- L’utilisateur possède un compte livreur

44
 - L’utilisateur s’est authentifié

Postconditions : aucun

Scénario nominal :

1. L’utilisateur arrive sur la liste des livraisons après son authentification

2. Il clique sur une livraison
3. L’application affiche les détails de la livraison

Scénario alternatif :

1a – Aucune livraison disponible

Le système n’affichera rien

5.3.7 Diagramme des séquences système pour chaque cas d’utilisation

Un diagramme de séquence est un diagramme d'interaction qui expose en détail la

façon dont les opérations sont effectuées : quels messages sont envoyés et quand ils le sont.
Les diagrammes de séquence sont organisés en fonction du temps. Le temps s'écoule au fur et
à mesure que vous parcourez la page. Les objets impliqués dans l'opération sont répertoriés de
gauche à droite en fonction du moment où ils prennent part dans la séquence de messages. [8].

Il fait ressortir :

- Les acteurs : représentés par un bonhomme et une ligne verticale (ligne de vie).
- Les objets : représentés par un rectangle et une ligne verticale (ligne de vie de l’objet).
- Les messages : traduisent les interactions (échange d’informations) entre objets. Ils
sont représentés par des flèches orientées de l’émetteur au récepteur. Deux types de
messages peuvent être distingués [2]:
 Message synchrone : Dans ce cas l’émetteur reste en attente de la réponse à
son message avant de poursuivre ses actions. La flèche avec extrémité pleine
symbolise ce type de message. Le message retour peut ne pas être représenté
car il est inclus dans la fin d’exécution de l’opération de l’objet destinataire du
message.

45
  Message asynchrone : Dans ce cas, l’émetteur n’attend pas la réponse à son
message, il poursuit l’exécution de ses opérations. C’est une flèche avec une
extrémité non pleine qui symbolise ce type de message.

Le fonctionnement d’un cas d’utilisation est notamment décrit sous la forme d’une
séquence de message échangé entre les acteurs et le système. Le système est vu de l’extérieur
(par les acteurs) sans préjuger de comment il est réalisé. On obtient donc le diagramme de
séquence système.

La figure 9 représente le diagramme de séquence pour s’authentifier.

46
Figure 9. Diagramme de séquence : « S’authentifier »

47
 La figure 10 illustre le diagramme de séquence pour le cas d’utilisation « S’inscrire en
tant que livreur ».

Figure 10. Diagramme de séquence : « S'inscrire en tant que livreur »

48
 La figure 11 représente le diagramme pour le cas d’utilisation « Afficher liste des
livraisons », « Voir la liste des livraisons recommandées », « Voir la liste de livraisons en
cours » et « Voir les demandes de livraisons ». 

Figure 11. Diagramme de séquence : « Voir liste livraisons »

49
La figure 12 illustre le cas d’utilisation « Afficher les détails d’une livraison ».

Figure 12. Diagramme de séquence : « Afficher détails livraison »

50
 La figure 13 nous le diagramme de séquence du cas d’utilisation « Confirmer une
livraison ».

Figure 13. Diagramme de séquence : « Confirmer une livraison »

51
 La figure 14 représente le diagramme de séquence du cas d’utilisation « Modifier
trajet ».

Figure 14. Diagramme de séquence : « Modifier trajet »

52
5.4 Spécifications des besoins techniques

Ce sont les besoins permettant de caractériser les contraintes organisationnelles et

techniques relatives à la configuration du réseau matériel. L’application doit être :

- Valide : aptitude d’un logiciel à réaliser exactement les tâches définies par les
entrepreneurs.
- Conviviale : le logiciel doit être facile à utiliser comme la simplicité des interfaces.
- Efficace : avec le nombre important des actions fournis, la durée d’exécution des
traitements doit être rapide.
- Fiable : aptitude du logiciel à assurer de manière continue la possibilité de consulter le
service attendu comme la disponibilité de téléchargement de la table de capitalisation
pour voir suivre le cours des actions de l’entreprise.
- Portable : facilité à être porté sur de nouveaux environnements matériels et logiciels
comme son fonctionnement sous différents systèmes.
- Extensible : facilité d’adaptation du logiciel aux changements de spécifications.
- Intègre : l’application doit être apte à protéger ses différents composants par le biais de
l’authentification et la gestion de droit des utilisateurs.
- Facile à entretenir : codes claires et lisibles facilitant tout changement et amélioration.

5.5 Modélisation du domaine

La modélisation des besoins par des cas d'utilisation s'apparente à une analyse
fonctionnelle classique. L'élaboration du modèle des classes du domaine permet d'opérer une
transition vers une véritable modélisation objet. L'analyse du domaine est une étape
totalement dissociée de l'analyse des besoins. Elle peut être menée avant, en parallèle ou après
cette dernière. [7].

53
La figure 15 illustre le modèle de domaine du système.

Figure 15. Modèle du domaine

54
 CHAPITRE 6 : CONCEPTION DETAILLEE

Dans ce chapitre, nous allons voir l’architecture logicielle utilisées, et les étapes de
procédé du système.

6.1 Architecture du système orientée services

Angular est un Framework Javascript basé une structure MVC du côté client. Il
apporte au client les services utilisés habituellement côté serveur, chaque page se retrouve
ainsi décomposée sous forme d’un modèle, d’une vue et d’un contrôleur. Le contrôleur et le
modèle sont représentés sous forme de classe, et la vue en fichier HTML.

Notre application a donc une architecture MVC dont les couches sont les suivants :

 Le modèle :
Selon Angular, le modèle représente les données de l’application et les règles de
validation associées grâce au TypeScript.
 La Vue :
C’est ce que verra l’utilisateur, générée à partir d’un template qui est un fichier HTML
enrichi de certains attributs et fonction propres à Angular, et du SCSS pour embellir
les pages.
 Le contrôleur :
Le contrôleur contient toute la logique de l’application et interagit avec le modèle pour
obtenir et mettre à jour les données. Il détermine également comment la vue doit être
mise à jour en fonction des actions de l’utilisateur.

La figure 16 nous montre la structure MVC d’Angular.

55
 Les données sont récupérées auprès du serveur via des requêtes http puis sont

Figure 16. Structure MVC d'Angular

interprétées et affichées au visiteur. Tout ceci permet de supprimer une bonne partie de la
charge de travail supportée par le backend conduisant ainsi à des applications web plus
légères.

56
6.2 Diagramme de séquence de conception pour chaque cas d’utilisation

Le diagramme de séquence de conception est un diagramme de séquence qui est plus

détaillé. En effet, le diagramme de séquence système ne montre que les scénarios d’échange
de messages entre les acteurs et le système tandis que le diagramme de séquence de
conception permet de donner une vue « en largeur » du déroulement d’une opération en
montrant tous les objets impliqués et en donnant plus de détails sur la façon dont cette
méthode procède.

L’utilisateur de l’application n’interagit qu’avec l’interface de l’application. Celle-ci

interfère ensuite avec le service qui envoie les requêtes et récupère les données dans la base.

La figure 17 illustre le diagramme de séquence de conception « Authentification »

Figure 17. Diagramme de séquence de conception : « S'authentifier » 57

 La figure 18 représente le diagramme de séquence de conception du cas d’utilisation «
S’inscrire en tant que livreur »

Figure 18. Diagramme de séquence de conception : « S'inscrire en tant que livreur »

La figure 19 illustre le diagramme de séquence de conception du cas d’utilisation

« Consulter la liste des livraisons ».

58
59
 Figure 19. Diagramme de séquence de conception: « Consulter liste des livraisons »

La figure 20 représente le diagramme de séquence de conception du cas d’utilisation «

Confirmer une livraison ».

Figure 20. Diagramme de séquence de conception : « Confirmer livraison »

60
 La figure 21 représente le diagramme de séquence de conception du cas
d’utilisation « Modifier trajet »

Figure 21. Diagramme de séquence de conception : « Modifier trajet »

61
6.3 Diagramme de classe de conception pour chaque cas d’utilisation

Avant d’établir le diagramme de classe de conception global, voyons d’abord les

diagrammes de classe pour chaque cas d’utilisation.

a- Diagramme de classe de conception pour le cas d’utilisation : S’inscrire

La Figure 22 représente le diagramme de classe de conception pour le cas d’utilisation

« S’inscrire ». A savoir qu’il faut un compte User avant de pouvoir avoir un compte Livreur.

Figure 22. Diagramme de classe de conception : « S’inscrire en tant que livreur »

b- Diagramme de classe de conception pour le cas d’utilisation : « S’authentifier »

La figure 23 représente le diagramme de classe de conception pour le cas

d’utilisation : S’authentifier

62
 Figure 23. Diagramme de classe de conception : « S'authentifier »

c- Diagramme de classe de conception du cas d’utilisation :  « Voir la liste des livraisons »

La figure 24 nous illustre le diagramme conception du cas d’utilisation « Voir la liste

des livraisons », « voir les livraisons recommandées », « voir les livraisons en cours », et voir
les demandes de livraison

Figure 24. Diagramme de classe de conception : « Voir liste livraisons »

63
d- Diagramme de classe de conception du cas d’utilisation :  « Voir détails livraison »
La figure 25 nous montre le diagramme de classe de conception du cas d’utilisation
Voir détails livraison.

Figure 25. Diagramme de classe de conception : « Voir détails livraison »

e- Diagramme de classe de conception du cas d’utilisation : « Confirmer livraison »

La figure 26 nous montre le diagramme de classe de conception du cas d’utilisation

Confirmer livraison

Figure 26. Diagramme de classe de conception : « Confirmer une livraison »

64
f- Diagramme de classe de conception du cas d’utilisation  :  « Modifier trajet »
La figure 27 nous montre le diagramme de classe de conception du cas d’utilisation :
Modifier trajet

Figure 27. Diagramme de classe de conception : « Modifier trajet »

6.4 Diagramme de classe de conception globale

Le diagramme de classe constitue l’un des pivots essentiels de la modélisation avec

UML. En effet, ce diagramme permet de donner la représentation statique du système à
développer. Cette représentation est centrée sur les concepts de classe et d’association.
Chaque classe se décrit par les données et les traitements dont elle est responsable pour elle-
même et vis-à-vis des autres classes. Les traitements sont matérialisés par des opérations [1].

La description du diagramme de classe est basée sur : le concept d’objet, le concept de

classe comprenant les attributs et les opérations, les différents types d’association entre les
classes.

65
La figure 28 indique le diagramme de classe de conception globale.

Figure 28. Diagramme de classe de conception globale

66
6.5 Diagramme de paquetage

Le diagramme de paquetage est un diagramme qui permet de visualiser la manière

dont les différents éléments du modèle sont organisés en groupe et en sous-groupes, et
comment ils interagissent entre eux.

La figure 29 représente le diagramme de paquetage

Figure 29. Diagramme de paquetage

6.6 Diagramme de déploiement

Le diagramme de déploiement est un diagramme qui permet de visualiser les différents

éléments du système. Il montre la configuration du système, et schématise les relations entre
les divers composants comme le montre la figure 30.

67
 Figure 30. Diagramme de déploiement

PARTIE III : REALISATION

68
 CHAPITRE 7 : Mise en place de l’environnement de
développement
7.1 Installation et configuration des outils

7.1.1 Visual Paradigm

Visual Paradigm est un logiciel de modélisation de systèmes d’information qui permet

aux utilisateurs de créer et de gérer des modèles de données. Visual Paradigm offre également
plusieurs outils pour réaliser les différents diagrammes UML.

La figure 31 nous montre l’installation de Visual Paradigm.

Figure 31. Installation Visual Paradigm

69
 7.1.2 MongoDB et MongoDB Compass

Comme déjà mentionné, pour la base de données, Mongo DB est la plus optimale dû à
sa flexibilité. En effet, il s’agit d’un système de gestion de base de données NoSQL qui
permet de gérer de grandes quantités de données non structurées.

MongoDB Compass est un outil de visualisation et de gestion de bases de données

MongoDB.

La figure 32 nous montre l’installation de MongoDB et MongoDB Compass

Figure 32. Installation MongoDB

La figure 33 ci-dessous représente l’interface de Mongo Compass

70
 Figure 33. Interface MongoDB Compass

7.1.3 Visual Studio Code

Comme IDE, on a utilisé VS Code qui est un éditeur de code développé par Microsoft,
disponible sur tous les systèmes d’exploitation. Pour son installation, il faut s’assurer d’avoir
au moins un espace libre de 250mo. Ensuite, il suffit de télécharger le ficher exécutable sur le
site officiel de Visual Studio Code.

Visual Studio Code est gratuit et facile d’accès.modèle

La figure 34 montre l’installation de Visual Studio Code.

71
 Figure 32. Installation Visual Studio Code
Figure 34. Installation Visual Studio Code

Au premier lancement, on aura une interface comme nous montre la figure 35

Figure 35. Interface Visual Studio Code

72
7.2 Architecture de l’application

REST ou Representational State Transfer est un Design Pattern permettant la

réalisation de divers types d’applications.

Dans une architecture REST, les ressources sont identifiées par des URI (Uniform
Resource Identifier) et sont manipulées en utilisant des verbes HTTP tels que GET, POST,
PUT et DELETE. Chaque ressource peut avoir différentes représentations, comme du
HTML , du XML, ou du JSON . Dans notre cas, on utilisera du JSON.

L’architecture permet également une plus grande flexibilité grâce au principe de

l’indépendance du client et du serveur, c’est-à-dire que le client et le serveur peuvent évoluer
indépendamment l’un de l’autre.

La figure 36 nous montre un schéma simplifié de l’architecture REST.

Figure 36. Architecture REST

73
 CHAPITRE 8 : DEVELOPPEMENT DE L’APPLICATION

8.1 Création de la base de données

Une base de données permet de mettre des données à la disposition d'utilisateurs pour
une consultation, une saisie ou bien une mise à jour, tout en s'assurant des droits accordés à
ces derniers. Cela est d'autant plus utile que les données informatiques sont de plus en plus
nombreuses.

Dans la figure 37 et 38, nous pouvons voir la structure de la table Delivery et

DeliveryMan dans MongoDB Compass.

Figure 37. Collection Delivery

Figure 38. Collection DeliveryMan

74
8.2 Codage de l’application

8.2.1 Routing de l’application

La figure 39 et 40 nous montre les principales routes de l’application

La figure 41 présente la configuration de l’environnement, qui pour le moment, est

Figure 39. app.routing.ts

Figure 40. delivery routing

toujours en local.

Figure 41. Configuration environnement

75
Dans la figure 42, nous avons les chemins pour les différents API .

Figure 42. API routes

La figure 43, 44, 45 nous montre l’appel des API via le service api.service.ts

Figure 43. API: GET livraisons en cours

Figure44.
Figure 45.API:
API:GET
GETlivraisons
demandesrecommandées
de livraisons

76
 Ensuite, la figure 46 nous montrent l’implémentation des resolvers. Il s’agit d’un
service qui permet de résoudre les données nécessaires avant que la route ne soit chargée.

Figure 46. Resolver pour les demandes de livraisons

La figure 47

Figure 47. Fonction hydrateRequestDeliveryList()

dans une variable et de l’envoyer au resolver.

77
8.3 Présentation de l’application

Tout utilisateur doit tout d’abord s’inscrire avant de pouvoir accéder au module livrer.

Figure 48. Interface d'inscription

78
 La figure 49 nous montre la page d’authentification.

Figure 49. Interface d'authentification

Le menu de navigation des listes de livraisons sera présenté comme ci-dessous.

Figure 50. Menu Trouver livraison

79
 Figure 51. Menu Mes livraisons

La figure 52 nous montre la version mobile du menu de navigation.

80
 Après son authentification, le livreur pourra accéder à la liste des livraisons comme
présentée sur la figure 53

Figure 53. Interface liste livraisons

La figure 54 représente l’interface lors de l’accès à une livraison, c’est-à-dire les

détails de la livraison.

81
 Figure 54. Interface détails d'une livraison

La figure 55 nous expose les différentes offres de la plateforme.

Figure 55. Offres de l'application

82
 CONCLUSION

RELIA Consulting fait partie des Entreprises au Service du Numérique (ESN) en

grande expansion à Madagascar. Se trouvant dans quartier d’Ambohimiandra, elle offre à ses
clients des produits du numérique de qualité. Ce stage s’est déroulé sous l’encadrement de
développeurs expérimentés.

Pour concevoir cette application, on a utilisé le langage de modélisation UML pour

réaliser les différents diagrammes nécessaires à la conception. Pour la réaliser, on a utilisé le
langage de programmation Javascript(NestJs pour le côté Backend, et Angular pour le côté
Frontend) et l’IDE Visual Studio Code, et finalement Figma pour la réalisation de la
maquette. De plus, les données sont stockées dans une base de données MongoDB.

L’application offre une opportunité de devenir livreur à plein temps, ou à temps partiel
selon le choix de l’utilisateur. Il pourra également voir toutes les livraisons aux alentours. De
plus, l’application a été réalisée depuis un design Mobile First, ce qui facilitera le travail des
livreurs car ils pourront voir les livraisons depuis leur téléphone avec une interface simple et
facile à utiliser.

L’application est toujours en cours de développement et sera utilisable dans quelques

mois, et les perspectives d’amélioration dans le futur sont toujours envisageables en ajoutant
certaines fonctionnalités comme le fait que le livreur pourra changer son statut de
disponibilité.

Ce stage a permis l’acquisition de nouvelles expériences professionnelles, ainsi qu’une

meilleure expérience de travail au sein d’une équipe, grâce à la méthode Agile.

x
 BIBLIOGRAPHIE

[1] Joseph Gabay- David Gabay, UML 2 Analyse et Conception, France, DUNOD, 2008,
226 pages.

[2] Brice Chaponneau, Vue.js Applications web complexes et réactives, EYROLLES,

2018, 256 pages.

WEBOGRAPHIE

[3] https://elearning-facsci.univ-annaba.dz, consulté en Janvier 2023

[4] https://fr.wikipedia.org/wiki/Langage_de_programmation, consulté en Janvier 2023

[5] https://fr.wikipedia.org/wiki/Cas_d%27utilisation, consulté en Janvier 2023

[6] https://www.lucidchart.com/pages/fr/langage-uml, consulté en Janvier 2023

[7] https://laurent-audibert.developpez.com/Cours-UML/?page=mise-en-oeuvre-uml#L9-
3-1UML%202, consulté en Janvier 2023

[8] https://docwiki.embarcadero.com/RADStudio/Sydney/fr/D
%C3%A9finition_des_diagrammes_de_s%C3%A9quence_UML_1.5, consulté en Janvier
2023

[9] https://www.cegos.fr/ressources/mag/projet/agilite/approche-traditionnelle-agilite-
differences, consulté en Janvier 2023

[10] https://www.tuleap.org/fr/agile/comprendre-methode-agile-scrum-10-minutes,
consulté en Janvier 2023

xi
 GLOSSAIRE

Architecture de microservices : Une architecture de microservices est une approche de

conception de logiciels qui consiste à construire une application comme une suite de services
autonomes qui communiquent entre eux.

Article : objet destiné à être commercialisé, à être vendu

Conception : Faculté de compréhension d’un domaine d’étude pour créer ou inventer le

résultat attendu

Framework : Espace de travail modulaire, ensemble de bibliothèques et de conventions

permettant le développement rapide d’application.

Livraison : Remise d’une marchandise à son acquéreur.

Méthode : Manière de faire une chose en suivant certains principes et avec un certain ordre.

Module :

NoSQL : Base de données non relationnelles. Elle offre des modèles de données plus
flexibles et plus évolutives.

Serveur : Ordinateur qui met ses ressources à la disposition d’autres ordinateurs sous la
forme de services

Super application : application qui regroupe sur sa plateforme une multitude de

fonctionnalités et des services

Trajet : Le fait de parcourir un certain espace, pour aller d'un lieu à un autre

xii
 ANNEXE

Voici un extrait de code pour récupérer les livraisons dans un rayon circulaire de 1km.

Figure 56. Code : récupération des livraisons recommandées

xiii
 TABLE DES MATIERES

CURRICULUM VITAE..............................................................................................................i

REMERCIEMENTS.................................................................................................................iii

LISTE DES TABLEAUX.........................................................................................................iv

LISTE DES FIGURES...............................................................................................................v

LISTE DES ABREVIATIONS................................................................................................vii

SOMMAIRE............................................................................................................................viii

INTRODUCTION GENERALE................................................................................................1

PARTIE I : PRESENTATIONS.................................................................................................2

CHAPITRE 1 : PRESENTATION DE L’ECOLE NATIONALE D’INFORMATIQUE.....3

1.1. Information d’ordre général.........................................................................................3

1.2. Missions et historique..................................................................................................3

1.3. Organigramme institutionnel de l’ENI........................................................................5

1.4. Domaine de spécialisation...........................................................................................6

1.5. Architecture des formations pédagogiques..................................................................7

1.6. Relations de l’ENI avec les entreprises et les organismes...........................................9

1.7. Partenariat au niveau international.............................................................................10

1.8. Débouchés professionnels avec des diplômés...........................................................12

1.9. Ressources humaines................................................................................................14

CHAPITRE 2 : PRESENTATION DE LA SOCIETE RELIA CONSULTING..................15

2.1 Présentation et historique............................................................................................15

2.2. Situation géographique de RELIA.............................................................................15

2.3 Missions de RELIA.....................................................................................................16

2.4 Organisation et fonctionnement de RELIA................................................................16

2.5 Organigramme............................................................................................................17

CHAPITRE 3 : DESCRIPTION DU PROJET.....................................................................19

xiv
 3.1 Formulation.................................................................................................................19

3.2 Objectif et besoins de l’utilisateur..............................................................................19

3.3 Moyens nécessaires à la réalisation du projet.............................................................20

3.4 Résultats attendus........................................................................................................20

3.5 Chronogramme...........................................................................................................21

PARTIE II : ANALYSE ET CONCEPTION...........................................................................22

CHAPITRE 4 : ANALYSE PREALABLE..........................................................................23

4.1 Analyse de l’existant...................................................................................................23

4.1.1 Organisation actuelle...........................................................................................23

4.1.2 Inventaire des moyens matériels et logiciels.......................................................23

4.2 Critique de l’existant...................................................................................................23

4.3 Conception de l’avant-projet.......................................................................................24

4.3.1 Proposition de solutions.......................................................................................24

4.3.2 Méthode de gestion de projet utilisée..................................................................25

4.3.3 Méthodes et outils utilisés....................................................................................29

CHAPITRE 5 : ANALYSE CONCEPTUELLE..................................................................35

5.1 Dictionnaire de données..............................................................................................35

5.2 Règles de gestion........................................................................................................37

5.3 Représentation et spécification des besoins................................................................37

5.3.1 Présentation d’UML.............................................................................................37

5.3.2 Identification des acteurs.....................................................................................39

5.3.3 Identification des messages..................................................................................40

5.3.4 Diagramme de cas d’utilisation...........................................................................41

5.3.6 Description textuelle de chaque cas d’utilisation.................................................43

5.3.7 Diagramme des séquences système pour chaque cas d’utilisation......................45

5.4 Spécifications des besoins techniques........................................................................52

5.5 Modélisation du domaine............................................................................................52

xv
 CHAPITRE 6 : CONCEPTION DETAILLEE.....................................................................54

6.1 Architecture du système orientée services..............................................................54

6.2 Diagramme de séquence de conception pour chaque cas d’utilisation.......................55

6.3 Diagramme de classe de conception pour chaque cas d’utilisation............................60

6.4 Diagramme de classe de conception globale..............................................................64

6.5 Diagramme de paquetage............................................................................................65

6.6 Diagramme de déploiement........................................................................................66

PARTIE III : REALISATION..................................................................................................67

CHAPITRE 7 : Mise en place de l’environnement de développement................................68

7.1 Installation et configuration des outils........................................................................68

7.1.1 Visual Paradigm...................................................................................................68

7.1.2 MongoDB et MongoDB Compass.......................................................................68

7.2 Architecture de l’application.......................................................................................71

CHAPITRE 8 : DEVELOPPEMENT DE L’APPLICATION.............................................73

8.1 Création de la base de données...................................................................................73

8.2 Codage de l’application..............................................................................................74

8.2.1 Routing de l’application.......................................................................................74

8.3 Présentation de l’application.......................................................................................78

CONCLUSION...........................................................................................................................x

BIBLIOGRAPHIE.....................................................................................................................xi

WEBOGRAPHIE......................................................................................................................xi

GLOSSAIRE............................................................................................................................xii

ANNEXE.................................................................................................................................xiii

TABLE DE MATIERES.........................................................................................................xiv

RESUME................................................................................................................................xvii

ABSTRACT...........................................................................................................................xvii

xvi
 RESUME

Ce stage au sein de l’ESN RELIA Consulting a pour objectif de mettre en place un

module de livraison de la super application AZPlus.

Ce projet permettra aux vendeurs d’offrir un service de livraison pour leurs produits et
aux livreurs de pouvoir effectuer ces livraisons.

De ce fait, la conception s’est faite grâce au langage de modélisation UML ; le

Backend a été réalisé avec du NodeJs, plus précisément avec le Framework NestJs, avec
MongoDB ; et le Frontend a été conçu avec Angular tout en utilisant l’IDE Visual Studio
Code.

Mots clés : module de livraison – super application – conception – NodeJs – NestJs-

MongoDB

Angular – Visual Studio Code

ABSTRACT

The goal of this internship at ESN RELIA Consulting is to set up a delivery module
for the super application AZPlus.

This project will allow sellers to offer a delivery service for their in-sale products and
for carriers to be able to make these deliveries.

Therefore, the was made using the UML modeling language; the Backend was
developed with Nodejs, more specifically with NestJs framework, with MongoDB; and
Frontend was designed with Angular using the Visual Studio Code IDE.

Keywords: delivery module – super application – design - NodeJs – NestJs- MongoDB

Angular – Visual Studio Code

xvii