Dedicace

A mes parents : Monsieur et madame AMOGO

1
Remerciements
 À Dieu Le Père omniscient, à qui nous rendons grâce notamment
pour la santé et l'engouement au travail qu'il a daigné nous accorder
tout au long de ce projet
 A madame la doyen de la faculté de sciences qui nous a permi
d'avoir une formation de qualité Au professeur BOWONG Sa-
muel notre chef de departement pour son encadrement et son soutien
 Au Dr MOSKOLAI Justin mon encadreur académique pour sa
disponibilité, ses conseils et sa bienveillance a mon egard
 A monsieur LIBAM Franck, directeur general de LONDO TECH-
NOLOGY pour l'accueil chaleureux au sein de son entreprise depuis
2 ans deja
 A ESSIAKOU Said mon encadreur professionnel qui a toujours fait
preuve de beaucoup de devaution dans l'encadrement
 A toute l'equipe LONDO avec qui je partage de bon moment
 A Patrick ATEBA, Murielle AMOGO merci a vous je vous aime
 A Marcelle MOGUEM et AMOGO Malik pour la force et le
soutien que vous me donner au quotidien
 A KAMDOM Biole mon frere Miagiste et dans la vie, merci pour
le soutien
 A tout le monde que je n'ai pas pu cité mais qui ont toujours été la
pour moi je vous dis merci

2
Liste DES ABREVIATIONS
 CSS : Cascading Style Sheets
 FTP : File Transfer Protocol
 HTTP : Hypertext Makeup Language
 EDI : Environnement de Développement Intégré
 MD5 : Message Digest 5
 MVC : Modèle Vue Contrôleur
 OMT : Object Modeling Technique
 OOSE : Object Oriented Software Engineering
 PAC : Présentation Abstraction Contrôle
 PBS : Product Breakdown Structure
 PME : Petites et Moyennes Entreprises
 UML : Unied Modeling Language
 WBS : Work Breakdown Structure
 2TUP : 2 Tracks Unied Process
 SSL : Secure Socket Layer

3
Table des gures

1.1 Logo de Londo Technology . . . . . . . . . . . . . . . . . . . . 17

1.2 Organigramme de l'entreprise . . . . . . . . . . . . . . . . . . 19

2.1 Product Breakdown Structure . . . . . . . . . . . . . . . . . . 29

2.2 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . 30

3.1 Diagramme de cas d'utilisation . . . . . . . . . . . . . . . . . 36

3.2 Diagramme de séquence d'authentication . . . . . . . . . . . 37
3.3 Diagramme de séquence des commandes . . . . . . . . . . . . 38
3.4 Diagramme de séquence des enlevements . . . . . . . . . . . . 39
3.5 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . 40
3.6 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 Shéma du processus SCRUM . . . . . . . . . . . . . . . . . . . 42

4.2 Shéma du MVC . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Logo Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4 Logo NodeJs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5 Schema SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6 Schema SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.7 Schema de l'architecture . . . . . . . . . . . . . . . . . . . . . 54
4.8 Home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.9 modal de connexion . . . . . . . . . . . . . . . . . . . . . . . 55
4.10 Liste des transporteurs . . . . . . . . . . . . . . . . . . . . . 56
4.11 Page d'assignation des AE . . . . . . . . . . . . . . . . . . . . 57

4
4.12 Page d'attribution des quais . . . . . . . . . . . . . . . . . . . 58

5
Liste des tableaux

1.1 Reference LONDO TECHNOLOGY MyCIMENCAM . . . . . 20

2.1 Partie prenante . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2 gestion des risques . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Risque lié à la réalisation du projet . . . . . . . . . . . . . . . 29

3.1 Choix de la méthode d'analyse . . . . . . . . . . . . . . . . . . 34

3.2 Fonctionnalité UML . . . . . . . . . . . . . . . . . . . . . . . 35

4.1 Tableau comparatif des modeles . . . . . . . . . . . . . . . . 43

4.2 Methode SCRUM . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3 tableau de modèle d'architecture . . . . . . . . . . . . . . . . . 45
4.4 Choix de l'environnement de développement intégré (EDI) . . 50

6
Table des matières

I CADRE ANALYTIQUE DE LA MISE EN PLACE

DE L'APPLICATION  FLUID  15
1 GENERALITE SUR LE PROJET 16
1.1 Présentation du cabinet LONDO TECHNOLOGY et ses réfé-
rences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.1 Le Cabinet . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.2 Les Domaines de compétence . . . . . . . . . . . . . . 17
1.1.3 Organigramme du cabinet . . . . . . . . . . . . . . . . 18

2 Cadrage du projet et analyse des besoins 21

2.1 Contexte et identication du projet . . . . . . . . . . . . . . . 21
2.1.1 Objectifs du projet . . . . . . . . . . . . . . . . . . . . 21
2.1.2 Enjeux du projet . . . . . . . . . . . . . . . . . . . . . 22
2.1.3 Spécications liées au projet . . . . . . . . . . . . . . 22
2.1.4 Méthodes et outil de management de projet utilisés . . 23
2.1.5 Les parties prenantes impliquées . . . . . . . . . . . . 24
2.1.6 Responsabilités des parties . . . . . . . . . . . . . . . . 24
2.1.7 Moyens de communication . . . . . . . . . . . . . . . . 25
2.1.8 La gestion des risques . . . . . . . . . . . . . . . . . . 25
2.2 Cahier de charge . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Fonctionnalités attendues . . . . . . . . . . . . . . . . 25
2.2.2 Périmètre du projet . . . . . . . . . . . . . . . . . . . . 27

7
 2.2.3 Population cible . . . . . . . . . . . . . . . . . . . . . . 27
2.2.4 Analyse fonctionnelle du projet . . . . . . . . . . . . . 27
2.2.5 Contraintes du projet . . . . . . . . . . . . . . . . . . 28
2.2.6 Risque lié à la réalisation du projet . . . . . . . . . . . 29
2.2.7 Planication du projet . . . . . . . . . . . . . . . . . . 29

II METHODOLOGIE ET APPROCHE 31
3 ANALYSE ET CONCEPTION DU SYSTEME 32
3.1 Analyse du système . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1 Choix de la méthode d'analyse . . . . . . . . . . . . . . 32
3.1.2 Acteurs et cas d'utilisations . . . . . . . . . . . . . . . 33
3.1.3 La vue des interactions systèmes . . . . . . . . . . . . 37
3.2 Conception détaillée du système . . . . . . . . . . . . . . . . 38
3.2.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . 38
3.2.2 Diagramme de déploiement . . . . . . . . . . . . . . . 39

4 IMPLEMENTATION DE LA SOLUTION 41
4.1 Choix du modèle de cycle de vie . . . . . . . . . . . . . . . . . 41
4.2 Choix du modèle d'architecture . . . . . . . . . . . . . . . . . 44
4.3 Outils de développement utilisés . . . . . . . . . . . . . . . . . 46
4.3.1 Choix du langage de programmation . . . . . . . . . . 47
4.3.2 Choix de l'environnement de développement intégré
(EDI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.3 Choix du système de gestion des bases de données . . 49
4.4 Méthode de sécurisation des données . . . . . . . . . . . . . . 51
4.4.1 Au niveau de la transmission . . . . . . . . . . . . . . 51
4.4.2 Au niveau de la reprise d'activité en cas de sinistre . . 53
4.5 Architecture de la solution . . . . . . . . . . . . . . . . . . . . 53
4.6 Présentation des résultats . . . . . . . . . . . . . . . . . . . . 53
4.6.1 Analyse des résultats . . . . . . . . . . . . . . . . . . . 58

8
4.6.2 Limite de la solution . . . . . . . . . . . . . . . . . . . 59

9
Resume
Dans le cadre de sa transformation digitale, l'entreprise CIMENCAM a
bien voulu se doter d'un logiciel de suivi des enlèvements et la traçabilité des
camions qui viennent chez eux récupérer la marchandise. Ce processus de di-
gitalisation a donc conduit notre entreprise Londo Technology a accompagné
l'entreprise dans cette tâche. L'objectif de ce travail est donc l'analyse, la
conception et le développement d'une application de gestion des enlèvements
et suivi de la otte. Parlant ici de gestion des enlèvements, nous faisons ré-
férence à l'ensemble des étapes qui partent de l'arrivé d'un camion a l'usine
jusqu'à sa sortie avec la marchandise du client. Pour répondre aux exigences
de la mondialisation qui se présente aujourd'hui comme un facteur de concur-
rence commercial, il est important de faire recours aux solutions web. Ainsi, à
l'aide des méthodes de gestion de projet et d'analyse tels que la méthode com-
parative ou analogique, le Work Breakdown Structure pour l'organigramme
des tâches et UML pour l'analyse du système, nous avons conçu, implémenté
et déployé un solution web auquel nous avons ajouté un ensemble de services
utiles et entièrement personnalisables pour l'organisation administrative.

10
Abstract
As part of its digital transformation, the company CIMENCAM was kind
enough to acquire software for monitoring removals and the traceability of the
trucks that come to them to collect the goods. This digitalization process has
therefore led our company Londo Technology has accompanied the company
in this task. The objective of this work is therefore the analysis, design and
development of an application for managing removals and monitoring the
eet. Speaking here of pick-up management, we are referring to all the steps
that start from the arrival of a truck at the factory until it leaves with the
customer's goods. To meet the demands of globalization, which is now a
factor of commercial competition, it is important to use web solutions. Thus,
using project management and analysis methods such as the comparative
or analog method, the Work Breakdown Structure for the work owchart
and UML for the system analysis, we designed, implemented and deployed a
web solution to which we have added a set of useful and fully customizable
services for the administrative organization.

11
INTRODUCTION
Le système d'information (SI) est aujourd'hui un outil stratégique pour le
management d'une entreprise et notamment celles à gouvernance complexe.
Ayant la volonté d'être compétitives. C'est en eet un support indispensable
au pilotage et à la prise de décision. Ces structures, présentes dans diérents
secteurs tels que la banque, l'industrie et le service, sollicitent pour cela des
éditeurs de logiciels ou bien des SS2I.
Les enjeux sont colossaux. Ces logiciels sur mesure décuplent les capacités
opérationnelles de l'organisation. Ils apportent une vision d'ensemble aux
fonctions transverses en facilitant le traitement des informations propres à
l'entreprise pour la collecte, la traçabilité, le partage, l'archivage et la diu-
sion. Ce moyen informatisé est un gain de temps dans la gestion des employés,
des clients, des stocks, de la fabrication, de la logistique ou encore dans la
comptabilité. N'importe où dans le monde, qu'elles soient PME ou multina-
tionales, elles peuvent, par l'intermédiaire de ces applications spéciques à
leurs activités, accroître leur performance de façon substantielle. Ainsi, face
à une demande importante, les fournisseurs sont inondés de contrats plus ou
moins juteux, ce qui créé un enthousiasme général dans le milieu de l'ingé-
nierie logicielle. De ce fait, les prestataires sont parfois prêts à prendre des
risques dans la conduite des projets. En eet, les SSII et les éditeurs de logi-
ciels jouent des coudes an de décrocher l'aaire du siècle. Sous la pression et
le besoin nancier, il est commun de proposer un délai très court et ce, même
si on sait à l'avance qu'on pourra dicilement le respecter ; ou bien d'annon-
cer un prix exagérément en deçà de la concurrence tout en sachant qu'il fau-
dra rogner sur un autre poste pour qu'il n'y ait pas de perte. Généralement,
une société qui éprouve le besoin de s'équiper d'une application, consulte
plusieurs sous-traitants et sélectionne l'ore la plus intéressante en termes de
coût et de délai. Dès lors qu'un client et qu'un prestataire contractualisent
leur relation commerciale, ce dernier établit un cahier des charges fonction-
nel. Puis sur le modèle en cascade, méthodologie standardisée et appliquée

12
pour gérer les diérentes étapes de développement, le fournisseur valide les
paliers les uns après les autres, jusqu'à la livraison à la partie prenante. Une
enquête réalisée par le Standish Group en 1994, nommée The Chaos Report,
met en lumière les taux d'échecs et de succès des projets informatiques . Elle
s'appuie sur une étude qualitative visant un panel de petites, moyennes et
grandes entreprises de secteurs tels que la banque, la nance, la production,
la santé, l'assurance, les services, le commerce ou encore des organismes lo-
caux et des administrations étatiques. L'organisme a centré son travail sur
les dépassements de coûts et de délais, la faiblesse des contenus puis a recensé
les facteurs de succès et de dégradation d'un projet. An d'être plus précis
dans ses résultats, le Standish Group a organisé des groupes de discussions,
composés de professionnels du secteur informatique. Le bilan de ce rapport
révèle une proportion d'échec des projets élevée, dont un tier abandonné en
cours de développement. Puis, il rapporte que l'excédent moyen de livraisons
hors délai est de 22%. Au niveau du contenu, seules 61% des fonctionnali-
tés spéciées initialement sont implémentées sur la version nale. La société
avance ensuite les facteurs de succès, de dégradation et de défaillance d'un
projet. De nombreux exemples sont énumérés ainsi que les pertes colossales
engendrées chirées en millions de dollars. Fort de ce constat, est né l'audit
des applications informatiques dans les années 70 et quelques années après
des référentiels donnant les bonnes pratiques en matière de développement
logiciel et plan de continuité des activités ont vu le jour.
Dans le cadre de son expansion, LONDO TECHNOLOGY fort de sa pre-
mière expérience MyCIMENCAM avec le géant de l'industrie CIMENCAM,
a été une fois de plus gagnant d'un appel d'ore qui représente le lot 2 du
processus de digitalisation des commandes et suivi des enlèvements en usine
chez CIMENCAM.
Créé en 2018, LONDO TECHNOLOGY est un cabinet spécialisé dans le
conseil IT, le développement et l'intégration de logiciels et applications. Notre
immersion dans l'environnement LONDO nous a amené a travaillé sur de

13
nombreuses applications et plus particulièrement sur l'application MyCI-
MENCAM , fort de mon expérience sur cette application, il m'a donc été
coné la conception et le développement de l'application dénommé FLUID
qui est entre autres une continuité de l'application MyCIMENCAM
Au vu de la tache qui nous a été coné, nous avons jugés opportun d'axer
notre thème d'étude sur la : L'ANALYSE, CONCEPTION ET DEVE-
LOPPEMENT DE l'APPLICATION WEB et MOBILE FLUID.
Le but de ce travail est de proposé à la n une application en production
exploitable par le client CIMENCAM.

 Le premier chapitre dénit le contexte général du projet et se compose

de deux parties. Une partie qui donne une présentation de la société
au sein de laquelle nous avons eectué le travail. Quant à la deuxième
partie, elle est consacrée à faire une étude préalable qui consiste à
étudier l'existant et les applications similaires qui existent déjà sur le
marché.
 Le deuxième chapitre va constituer au cadrage du projet et a l'analyse
des besoins
 Le troisième chapitre va permettre de faire une analyse et la concep-
tion du système
 Le quatrième chapitre sera consacré à l'implémentation de la solution
 Pour terminer, une conclusion permettant de faire une synthèse du
travail réalisé et de donner les perspectives avenir

14
 Première partie
CADRE ANALYTIQUE DE LA
MISE EN PLACE DE
L'APPLICATION  FLUID 

15
Chapitre 1
GENERALITE SUR LE PROJET

Nombreux sont les avantages aujourd'hui pour une entreprise qui eectue
sa transition digitale. Mark Andreessen, fondateur de Netscape le soulignait
encore avec sa fameuse maxime  Software is eating the world , pour signier
l'importance des nouvelles technologies de l'information et de la communi-
cation et des logiciels dans la société. Au Cameroun, le digital est de plus
en plus au c÷ur de la stratégie d'attraction et de rétention des publics et
prospects. La crise Corona virus en a fait une démonstration dans le monde.
Faciliter la communication et accélérer les processus dans un monde qui va
de plus en plus vite. Aujourd'hui, il faut vite faire, il faut bien faire. La forte
concurrence dans le développement de services pousse les entreprises à dé-
velopper les solutions informatiques de haute qualité dans de délais réduits.
Dès lors, il faut prendre en compte le strict nécessaire des fonctionnalités à
développer pour une première mise en production et d'apporter une amélio-
ration progressive.
Dans cette partie, nous allons tout d'abord présenter le cabinet LONDO
TECHNOLOGY.

16
1.1 Présentation du cabinet LONDO TECH-
NOLOGY et ses références
Présenter le cabinet LONDO TECHNOLOGY revient à parler de sa
structure et son organisation (1) puis de parler de sa gestion de projets (2).

1.1.1 Le Cabinet
LONDO TECHNOLOGY est un cabinet de conseil spécialisé dans la
conception, le déploiement, l'audit et la maintenance des systèmes d'infor-
mations. Situé en plein c÷ur de la capitale économique du Cameroun, il met
son expertise digitale au service de ses clients pour des prestations d'accom-
pagnement, de développement de logiciels adaptés aux réalités locales et de
formation.

Figure 1.1  Logo de Londo Technology

1.1.2 Les Domaines de compétence

Pour répondre de manière ecace aux besoins de ses clients, le cabinet a
axé son savoir-faire sur cinq piliers principaux : le Conseil, le développement
logiciel, l'Audit des Systèmes d'Informations, la formation et l'intégration des
solutions. Cela permet d'accompagner jours après jours les petites, moyennes
et grandes entreprises de divers secteurs d'activité.

Conseil
 Accompagnement AMOA et MOA

17
  Conseil en méthodologie de gestion des projets digitaux (Agile, LEAN...)

Développement logiciel
 Développement d'Application Web et Mobiles (Androïd et IOS)
 Développements logiciels pour desktop et tableaux de bord.
 Développement Logiciels de gestion de systèmes industriels

Audits des Systèmes d'Information

 Analyse des procédures
 Identication des KPIs et mise en place d'un suivi automatisé
 Paramétrages SI

Formations
 Utilisation d'outils technologiques
 Coaching du personnel technique

L'intégration de solutions
 Conguration d'ERP
 Intégration de modules AMPLITUDE
 Intégration des moyens de paiements numérique

1.1.3 Organigramme du cabinet

Les références présentées ainsi qu'il suit, font état de l'équipe de déve-
loppement et de l'ore de service pour l'application d'achat en ligne MYCI-
MENCAM.

Descriptif du Projet : Permettre l'achat en ligne des ciments et orir

des moyens de paiement simples et modernes à travers une application multi
plateforme :

18
 Figure 1.2  Organigramme de l'entreprise

 https ://play.google.com/store/apps/details ?id=com.mycimencam.mobile

(Androide)
 https ://apps.apple.com/us/app/mycimencam/id1467838902 (iOS)
 https ://mycimencam.com (web)
Descriptif des services fournis par notre personnel :
 Prise de commande en ligne
 Paiement électronique des commandes (Orange Money, MTN Mobile
Money, Compte CIMENCAM...)
 Planication de l'enlèvement des produits en usine
 Suivi en temps réel du statut de la commande et des livraisons
 Réception et validation des commandes et émission des Attestations
d'Enlèvement
 Gestion et suivi de l'enlèvement en usine
 Relevé automatique des indicateurs de performance de l'activité

19
Nom de la mission : Réalisation d'une application
mobile Android et iOS, ainsi qu'un site web pour l'achat
de ciment en ligne
Valeur approximative en FCFA : Condentiel
Date d'achèvement : Septembre 2019
Temps de travail : 07 mois
Date de début : Octobre 2018
Date de n : Avril 2019
Table 1.1  Reference LONDO TECHNOLOGY MyCIMENCAM

20
Chapitre 2
Cadrage du projet et analyse des
besoins

Ce projet de mémoire a pour but de mener la réalisation d'un thème pra-

tique à partir des connaissances acquises durant l'année académique et lors
du stage en entreprise. Ainsi, il sera donc question pour nous de mettre sur
pieds une solution web et mobile de gestion de la logistique qu'on nommera
ici FLUID, donc le choix des technologies et la logique de développement
reèteront les compétences acquises au cours du cursus.

2.1 Contexte et identication du projet

2.1.1 Objectifs du projet
Nos objectifs tout au long de ce travail seront donc :
 D'appréhender le concept et de comprendre le fonctionnement de la
gestion des enlèvements
 D'identier les axes stratégiques pour l'aide à l'administration et a la
logistique
 De concevoir, de modéliser et d'implémenter un système Informatique,

21
 pour l'aide à l'amélioration de la gestion des enlèvements chez Cimen-
cam

2.1.2 Enjeux du projet

Les enjeux liés à ce projet sont d'ordre technologiques et économiques

Les enjeux technologies

 La modélisation et l'implémentation d'un système informatique pour
l'aide à la logistique
 La valorisation du BYOD (Bring Your Own Device) par l'utilisation
des équipements personnels (ordinateur portable, tablette, téléphone
mobile ..) dans un cadre professionnel. Des appareils qui ne sont pas
toujours fournis par l'entreprise mais permettent au personnel de se
connecter au réseau interne

Les enjeux économiques

 Garantir une bonne croissance de l'économie des entreprises via une
administration des activités plus exible, sécurisée, mobile et plus
able ;
 Réduire les coûts liés à la gestion administrative.

2.1.3 Spécications liées au projet

Spécication globale
La présente consultation consiste à faire la conception, l'implémentation
d'une solution web et mobile de gestion de la logistique et le suivi de la otte

22
Spécication temporelle
Tout projet digne de ce nom est conditionné par un temps de mise en
÷uvre en fonction des coûts et des équipements disponibles. Ainsi La mise
sur pied d'un tel projet passe par le respect du temps qui nous a été alloué à
savoir quatre (02) mois pour les développements et une mise en phase pilote.
Nous ferons alors usage des outils mis à notre disposition pour pouvoir réaliser
ce travail.

Spécication budgétaire
Vu que nous sommes dans le cadre d'un marché qui a été gagné par notre
entreprise, nous sommes dans l'incapacité de divulgué les montants alloués
au projet.

2.1.4 Méthodes et outil de management de projet uti-

lisés
Les méthodes et outils servent à structurer une démarche de progrès ; elles
évitent d'oublier des étapes essentielles comme celle de préparer avant d'agir.
La préparation est en eet essentielle et très liée à la phase de vérication : On
ne pourra vérier que par rapport à la préparation. Les diérents méthodes
et outils seront les suivants :
 La Méthode SMART : Qui permet de xer les objectifs liés à un
projet
 Le Product Breakdown Structure (PBS) : Pour le découpage du
projet en produits et sous-produits
 Le Work Breakdown Structure (WBS) : Pour la hiérarchisation
des tâches
 Le diagramme pieuvre : C'est un outil utilisé pour analyser les
besoins et identier les fonctions de service d'un produit. Il met évi-
dence les relations entre les diérents éléments du milieu environnant

23
 Désignation Fonction
CIMENCAM Maître d'ouvrage (MOA)
LONDO TECHNOLOGY Maître d'÷uvre (MOE)
AMOGO FABRICE JUNIOR Chef de projet
Table 2.1  Partie prenante

et le produit. Il nous permettra d'eectuer une analyse fonctionnelle

externe du projet

2.1.5 Les parties prenantes impliquées

Une partie prenante est un acteur, individuel ou collectif (groupe ou
organisation), activement ou passivement concerné par une décision ou un
projet. Les parties prenantes sont regroupées dans le tableau ci-dessous :

2.1.6 Responsabilités des parties

Maitre d'ouvrage
La maitrise d'ouvrage est représentée ici principalement par le Client. Le
Client a comme obligations de :
 Mettre à la disposition du (des) prestataire(s) tous les documents et
informations nécessaire à la réalisation du logiciel
 De valider le recettage du projet
 Valider chaque étape de l'avancement du projet

Maitre d'÷uvre
Il a pour obligations de :
 Réaliser la plateforme
 Mettre en ÷uvre l'application mobile

24
  Mettre à disposition le code source de la plateforme et la base de
données
 Faire valider le produit nal, le faire tester et apporter les corrections
demandées par le client

2.1.7 Moyens de communication

Le travail en équipe est un mode de fonctionnement particulièrement e-
cace qui permet la complémentarité des compétences, permet de prendre de
meilleures décisions et mieux pouvoir analyser les conséquences des décisions
avant de les mettre en ÷uvre .
Ainsi la stratégie de communication choisie est la suivante :
 Les réunions hebdomadaires pour informer sur l'état d'avancement
 La messagerie électronique professionnelle
 Les appels téléphoniques

2.1.8 La gestion des risques

La gestion des risques (RSKM, Risk Management) consiste à identier
des problèmes potentiels avant qu'ils ne surviennent, de telle sorte que les
activités pour traiter les risques puissent être planiées et déclenchées au
besoin tout au long de la vie du produit ou du projet an que les impacts
nuisibles à l'atteinte des objectifs soient atténués .

2.2 Cahier de charge

2.2.1 Fonctionnalités attendues
Les fonctionnalités liées à l'application ont été déni grâce à la méthode
SMART qui permet de xer les objectifs selon le niveau de détail, l'état
d'avancement, l'accessibilité, le niveau de réalisme, et le temps déni. Ainsi

25
 Source Risque Processus de gestion
Estimation Coût Prévoir 10 pourcent de marge sur le
coût total du projet
Evénements Imprévus Délai Prévoir une marge de 2 jours au moins
pour la Réalisation de chaque tâche
Développement de la solu- Qualité Faire intervenir les parties prenantes à
tion toutes étapes de réalisation de la solu-
tion
Table 2.2  gestion des risques

nous avons :

Fonctionnalités globales
L'application que nous devons concevoir devra permettre de gérer confor-
mément au cahier de charge
 Gérer les commandes en interne de type ST
 Gérer le suivi de la otte
 Gérer les inspections des camions
 Faire un suivi des camions
 Attribuer des autorisations d'enlèvements au transporteur
 Faire un suivi des transporteurs
 Faire un suivi des chaueurs
 Faire un reporting sur toutes les données recueillies dans l'application
 Faire une gestion administrative
L'application doit aussi pouvoir être
 Multi-plateforme : Elle sera adaptée pour diérents supports tels
que mobiles, PC, et tablettes
 Hautement sécurisée
 Multi-utilisateurs
 Facile d'utilisation

26
  Attrayante.

2.2.2 Périmètre du projet

Le périmètre du projet se limite à la mise sur pied d'une plateforme Web
et mobile de gestion des enlèvements et suivi de la otte et au déploiement
de cette application.

2.2.3 Population cible

Pour l'entreprise LONDO Technology il est question de produire un lo-
giciel sur mesure pour le géant du secteur du ciment CIMENCAM et avoir
une application qui peut être modulable et vendable a d'autres industriels

2.2.4 Analyse fonctionnelle du projet

Il s'agit d'une démarche pour identier les besoins des clients. Cette mé-
thode a été mise au point par Lawrence Delos Miles aux États-Unis vers
1950. Pour un produit, un procédé de fabrication ou une organisation, il faut
savoir répondre à des questions simples et fondamentales :
 À quoi ça sert pour les clients ?
 Pourquoi le client a-t-il ce besoin ?
 À qui cela rend-il service ?
 Sur quel processus et sur qui cela agit-il ?
 Quelles sont les fonctions principales du produit ?
 Comment caractériser les besoins du client, les valoriser et les hiérar-
chiser en poids relatif ?
 Quels sont les buts ?
 Quels sont les risques d'évolutions ou de disparitions du besoin ?

27
2.2.5 Contraintes du projet
Les trois contraintes : Délais, coûts et qualités sont présentes pour chaque
projet. Il arrive parfois que l'une de ces contraintes puisse mettre en péril la
réalisation du projet. Il s'avère par conséquent utile de les maitriser an
d'anticiper tous les problèmes qui peuvent être rencontrés.

Qualité
La contrainte de qualité constitue un aspect très important. La qualité ne
pouvant jamais être parfaite, elle doit cependant s'approcher le plus possible
du zéro défaut. Cette contrainte constitue un gage de sécurité et ne doit pas
être probabiliste. L'application devra être :
 Facile d'utilisation : Porte sur l'eort nécessaire pour apprendre à
manipuler le logiciel
 Fiable : Capacité à rendre des résultats corrects quelles que soit les
conditions d'exploitation
 Performante : Le rapport entre la quantité de ressources utilisées
(moyens matériels, temporelles, humaines), et la quantité de résultats
délivrés
 Maintenable : Porte sur l'eort nécessaire en vue de corriger ou de
transformer le logiciel

Contrainte de limitation
Il est important de noter que notre champ d'étude se limitera sur la
gestion des enlèvements en usine et au suivi de la otte.
Les livrables attendus
 Le Dossier d'analyse : Permet de décrire le système, ressortir les
acteurs, les fonctionnalités et les objets du système
 Dossier de conception : Donnera le squelette de l'application
 Manuel d'utilisation : Donnera le mode d'emploi de l'application

28
 Risques envisageables Solutions envisageables
Sécurité des données Dans ce cas, nous opterons
pour l'utilisation de certi-
cats SSL (Secure Sockets
Layer) pour la sécurisation
des échanges
Blocage technique lié par- Dans ce cas, nous nous
fois a la compréhension du rapprochons du client pour
besoin éclaircissement
Table 2.3  Risque lié à la réalisation du projet

2.2.6 Risque lié à la réalisation du projet

2.2.7 Planication du projet
Le Product Breakdown Structure est une décomposition organisée et
cohérente du projet en produits ou modules et sous-produits ou sous-modules.
C'est l'expression exacte de tout (matériel, logiciel), ce qui doit être accompli
pour arriver à la n du projet.

Figure 2.1  Product Breakdown Structure

29
Diagramme de GANTT
Conçu à partir du Work Breakdown Structure (WBS), Le diagramme de
Gantt donne une vue globale du projet, et permet de visualiser dans le temps
les diverses tâches.
Diagramme des ressources
Le diagramme des ressources permet de mettre en exergue la répartition des
tâches entre les acteurs liés à la réalisation du projet
Le bilan de ce chapitre met en exergue le projet à réaliser à travers une

Figure 2.2  Diagramme de Gantt

dénition claire des besoins fonctionnels et non fonctionnels, une planication

ecace des tâches à réaliser pour la réussite du projet et une estimation des
coûts plus que précise à l'aide des méthodes de management des coûts du
projet. Reste maintenant à dénir la méthodologie utilisée pour la mise en
place d'une telle solution.

30
 Deuxième partie
METHODOLOGIE ET
APPROCHE

31
Chapitre 3
ANALYSE ET CONCEPTION
DU SYSTEME

En connaissance des concepts, de l'état du savoir et du savoir-faire en ma-

tière de gestion des enlèvements et suivi de la otte, nous pouvons à présent
faire face à notre problème qui est de proposer une solution pour l'améliora-
tion de celle-ci s'appuyant sur les TIC (Technologie de l'information et de la
communication), penser et concevoir une qui pourrait se positionner comme
préférentielle, compte tenu de son contexte d'implémentation. Ce chapitre
vise donc à dénir clairement les besoins à satisfaire par cette solution, et à
mettre sur pied une architecture conceptuelle approprié

3.1 Analyse du système

3.1.1 Choix de la méthode d'analyse
Pour programmer une application, il ne convient pas de se lancer tête
baissée dans l'écriture du code : il faut d'abord organiser ses idées, les docu-
menter, puis organiser la réalisation en dénissant les modules et étapes de

32
la réalisation. Cette démarche antérieure a l'écriture que l'on appelle modé-
lisation a pour produit un modèle. Le tableau suivant illustre les méthodes
d'analyses les plus connues.

Les méthodes de modélisation ou d'analyse ont l'objectif commun de per-

mettre que le système soit compréhensible par toutes les parties prenantes
actuelles et futures du projet.
Ainsi, nous avons choisi le langage UML pour la richesse des détails concep-
tuels qu'il ore et sa facilité d'interprétation. De plus, il garantit une bonne
compréhension des vues du système à mettre sur pied.
UML comprend 13 diagrammes regroupés en 5 grands groupes, que nous
présentons dans le tableau suivant

Cependant, tout au long de notre modélisation, nous ne ferons pas usage

de tous les diagrammes de chaque groupe, mais nous choisirons de manière à
garantir une compréhension rapide de notre système et de ses constituants.

3.1.2 Acteurs et cas d'utilisations

Identication des acteurs du système
Ici nous présentons les diérents intervenants dans l'application

 Le logisticien : il s'agit de la personne en charge de la gestion des

enlèvements et il a la possibilité de passer les commandes dans l'ap-
plication ;
 L'administrateur : Il sera chargé de mettre a jour ou d'ajouter les
données dans l'application ;
 L'inspecteur : Il aura pour mission de faire l'inspection des camions
une fois leur arriver à l'usine

33
Concept Description
Merise (Méthode d'Etude et de Réa-Repose sur 5 principes fondamentaux
lisation Informatique par les Systèmes
qui ont précédé à son élaboration
d'Entre- prise) (l'approche systémique, les cycles de
construction des systèmes d'informa-
tion, l'approche fonc- tionnelle, la vi-
sion duale des données-traitement et
l'ap- proche du général au particulier).
UML (Unied Modeling Language) Langage graphique de modélisation de
données et de trai- tements.
SADT (Structured Analysis and De- Démarche systémique de modélisation
sign Technique) d'un système com- plexe ou d'un pro-
cessus opératoire.
NIAM Méthode d'analyse et de conception
pour les systèmes d'information.
OMT (Object Modeling Technique) méthode qui permet de couvrir l'en-
semble des processus d'analyse et de
conception en utilisant le même forma-
lisme. L'analyse repose sur les trois
points de vue : sta- tique, dynamique,
fonctionnel. Donnant lieu à trois sous-
modèles.
Booch Méthode qui permet de faciliter l'im-
plémentation de pro- grammes dans
des langages de programmation orien-
tée objet, ainsi que de représenter les
diérentes phases du Développement
d'un projet.
OOSE Méthode de développement créée par
Ivar Jacobson, ca- ractérisée par la dé-
nition des  use cases  (cas d'utili-
sation). Elle a été intégrée dans UML à
partir de 1995.
2TUP Processus de développement logiciel
qui bénécie de la maturité de nom-
breuses méthodes telles qu'OOSE,
BOOSH, OMT.
Table 3.1  Choix de la méthode d'analyse
34
 Vues Diagrammes utilisés
Vue comportementale Diagrammes d'états transition, d'acti-
vités, de séquences sys- tème, de colla-
boration, global d'interaction, de temps
Vue logique Diagrammes de classes, d'objets
Vue d'implémentation Diagrammes de composants et de struc-
ture composite
Vue de déploiement Diagramme de déploiement

Table 3.2  Fonctionnalité UML

Identication des cas d'utilisation

Les cas d'utilisation du système sont repartis de la façon suivante :
Le logisticien
 Passer les commandes de type ST ;
 Planier les enlèvements des commandes ;
 Consulter la liste des autorisations d'enlèvements ;
 Attribuer une autorisation d'enlèvement a un transporteur
 Désassigner une autorisation d'enlèvement a un transporteur ;
 Attribuer un quai de chargement a un camion ;
 Changer de quai de chargement a un camion ;
 Mettre un camion hors de la le d'attente
L'administrateur
 Créer les comptes utilisateurs et leurs attribuer des rôles ;
 Ajouter des transporteurs et avoir la possibilité de les éditer ;
 Ajouter des chaueurs et avoir la possibilité de les éditer ;
 Ajouter des véhicules et avoir la possibilité de les éditer
 Ajouter des produits et avoir la possibilité de les éditer ;
 Ajouter des ores de prix et avoir la possibilité de les éditer ;
 Avoir l'historique de toutes les transactions qui sont faites dans l'ap-
plication ;
 Avoir la possibilité de faire des extractions de données sous diérents

35
 formats ;
 Voir les reporting sur les données de l'application
L'inspecteur
 Faire un checking des camions à leur arriver ;
 Avoir un historique des camions checker ;
L'inspecteur
 Faire un checking des camions à leur arriver ;
 Avoir un historique des camions checker ;
Le transporteur
 Valider une autorisation d'enlèvement ;
 Refuser une assignation d'autorisation d'enlèvement ;

Figure 3.1  Diagramme de cas d'utilisation

36
3.1.3 La vue des interactions systèmes
Notre système, prenant en charge l'interaction d'une multitude d'utilisa-
teur connectés, doit pouvoir identier de façon indépendante la contribution
de chaque utilisateur dans l'application. La première chose à faire quand tu
as le lien vers notre application est la connexion. Un utilisateur doit pouvoir
se connecter pour avoir accès à son interface

Figure 3.2  Diagramme de séquence d'authentication

Processus de commande
Pour parler de processus de commande, il faudrait que l'utilisateur ce
soit au préalable connecté l'application, une fois qu'il s'est authentié, il a la
possibilité de passer une commande et ceci en commençant par le choix du
point de vente. La suite est décrite dans le tableau ci-après

Processus d'enlèvement
Le processus d'enlèvement concerne le logisticien qui une fois connecté a
la possibilité de voir toutes les autorisations d'enlèvements disponible dans

37
 Figure 3.3  Diagramme de séquence des commandes

l'application qui ont été récupérer depuis l'ERP JDE utilisé par CIMEN-
CAM.
Le logisticien ici assigne une autorisation d'enlèvement a un transporteur qui
après validation envoie à l'usine le jour de l'enlèvement un chaueur avec un
camion qui va suivre toutes les étapes décrites dans le diagramme de séquence
suivant

3.2 Conception détaillée du système

3.2.1 Diagramme de classe
Alors que le diagramme de cas d'utilisation montre un système du point
de vue des acteurs, le diagramme de classe montre la structure interne. Il
permet de fournir une représentation abstraite des objets du système qui
vont interagir ensemble pour réaliser les cas d'utilisation. La gure suivante

38
 Figure 3.4  Diagramme de séquence des enlevements

nous illustre cela.

3.2.2 Diagramme de déploiement

Un diagramme de déploiement décrit la disposition physique des res-
sources matérielles qui composent le système et montre la répartition des
composants sur ces matériels.
Au terme de ce chapitre, nous avons un vison conceptuel bien détaillée
de notre solution, en eet nous avons après une analyse s'appuyant sur les
résultats, indications et recommandations able mis sur pieds et modélisé la
solution que nous proposons dans ses diérents aspects.
Nous pouvons donc des a présent passer à son implémentation

39
Figure 3.5  Diagramme de classe

Figure 3.6  Diagramme de classe

40
Chapitre 4
IMPLEMENTATION DE LA
SOLUTION

La mise sur pieds de la solution après une bonne analyse et une conception
ne pose généralement pas trop de problème au niveau de son implémentation.
Le souci généralement peut venir des technologies utilisées. Mais dans notre
cas, fort de notre niveau de maitrise en matière technologique, nous avons pu
produire une solution déjà en phase pilote chez le client et qui sera bientôt
en production conformément au cahier de charge

4.1 Choix du modèle de cycle de vie

Un modèle de cycle de vie est une représentation abstraite d'un ensemble
structuré d'activités nécessaires pour le développement d'un logiciel. Ils en
existent une panoplie, diérentes par la taille de l'équipe engagée dans le
projet, les besoins du client, le temps imparti et le budget alloué. Cepen-
dant, toutes sont structurées pour permettre la production d'un logiciel de
qualité, dèle aux spécications de départ. Entre spécication, conception,
implémentation, validation, amélioration ou maintenance, les modèles de pro-
cessus visent à accroître la productivité des équipes de développement.

41
Le tableau ci-dessous essaie de présenter diérents modèles de processus
parmi les plus connus avec leurs avantages et inconvénients.
À la vue de ce tableau, on observe que, la composition de l'équipe enga-
gée dans le développement, le temps imparti, le budget, les contraintes de
livraison et les compétences techniques sont importantes pour xer le choix
du modèle de processus à adopter.
En eet, pour la réussite de ce projet, le travail en équipe et les démonstra-
tions ont été fortement sollicités pour fournir une solution de qualité. De plus
le cadre de travail doit permettre de répondre à des problèmes complexes,
tout en livrant de manière productive et créative des produits de la plus
grande valeur possible.
Cycle de vie et assurance qualité étant fortement liés, nous pouvons donc
pencher pour le modèle Agile 1 et plus précisément la méthode SCRUM 2
qui semble s'accommoder à ces contraintes mais requiert néanmoins énormé-
ment de temps dans la réalisation du projet.

Figure 4.1  Shéma du processus SCRUM

A l'aide de la méthode SCRUM, nous avons donc décomposé le projet à

réaliser en sous- projets facilitant ainsi l'implémentation, la maintenance et
les mises à jour du projet.

42
Modèles Avantages Inconvénients
V Très discipliné, marche bien pour Risque et incertitude élevé, non
de petits projets, simple et facile adé- quat aux projets complexes
d'utilisation et orientés objet, non adéquat
pour des projets comportant un
haut risque de changement
Spirale Possibilité d'adaptation en cas de Gestion plus complexe du projet,
changement des spécications, le la n du projet n'est pas très vite
développement peut être divisé en percep- tible, onéreux pour de pe-
petites parties, meilleure gestion tits projets, la spirale peut ne pas
des risques s'achever
Itératif Résultats périodiques, possibilité Requiert d'importantes res-
de développement parallèle, faible sources, dicile de changer les
coût de changement, test et dé- spécications initiales malgré la
buggage continu, meilleure ana- facile adaptation au changement,
lyse des risques) requiert beaucoup d'attention
managériale, incompatible aux
petits projets
RAD (Rapid Favorable au changement de spé- Dépend de l'habilité technique
Application cications, mesure de l'évolution, de l'équipe à détecter des outils
Development) évolution rapide en cas d'utilisa- puissants, seuls les systèmes mo-
tion de puissants outils, productif dulables peuvent être développés
avec un faible eectif, temps de avec ce modèle, requiert des dé-
développement réduit, encourage veloppeurs et concepteurs haute-
la réutilisation des composants. ment qualiés, complexité de ma-
nagement, adéquat pour les sys-
tèmes orientés composant et Sca-
lables
SCRUM Approche très réaliste pour le dé- Pas favorable à la gestion de
veloppement logiciel, encourage le dépendances complexes, risques
travail en équipe, possibilité de élevés de maintenance et d'ex-
développement et de démonstra- tensibilité, dépend de l'interac-
tion rapide des fonctionnalités, tion avec le client, manque de
ressources requises minimales, fa- documentation donc diculté de
vorable au changement de spéci- transfert technologique à une
cations, facile à manager nouvelle équipe
Table 4.1  Tableau comparatif des modeles

43
 Modules(Sprint)Prestations attendues Durée Livrable
Processus de Passer des commandes et 02 se- Interface graphique fonc-
commande planier les commandes maines tionnelle du processus de
commande
Processus de Pouvoir voir les diérents 01 semaine Interface graphique fonc-
reporting graphes de données tionnelle des reporting
Processus De l'attribution de l'assi- 04 se- Interfaces graphique fonc-
d'enlèvement gnation de l'AE a un trans- maines tionnelles de gestion des en-
porteur a sa mise en quai de lèvements
chargement et au début de
son voyage
Processus de Suivi de la otte une fois le 01 semaine Interface graphique fonc-
tracking voyage eectif et historique tionnelle de gestion du tra-
des voyages cking
Table 4.2  Methode SCRUM

4.2 Choix du modèle d'architecture

Les modèles d'architecture ont été développés pour structurer l'appli-
cation développée. Ils permettent de décomposer l'application en plusieurs
modules ayant chacun un rôle qui lui est attribué.
Le tableau ci-dessous essaie de présenter diérents modèles d'architecture
avec leurs avantages et inconvénients.

À la vue de ce tableau, il apparaît que la taille du projet, le périmètre

du projet, le temps imparti et la souplesse dans l'organisation du travail sont
importantes pour xer le choix du modèle de processus à adopter.
En eet la réussite de ce projet passe par une conception claire et ecace, une
grande souplesse dans l'organisation du travail et une intégration des parties
prenantes à toutes les étapes du projet qui sont les principaux  crédo du
modèle MVC. Le modèle MVC facilite également une amélioration continue
de la solution.

44
Modèles Avantages Inconvénients
ARCH Adapté aux interfaces à base de Il est abstrait car il ne précise pas
menus et d'écrans de saisie. Il dé- comment réaliser les diérentes
compose le logiciel en trois (03) parties et leurs interconnexions en
couches à savoir : La présentation utilisant les constructions dispo-
pour la vue, l'interface applica- nibles dans les langages de pro-
tion pour convertir les entrées de grammation.
l'utilisateur en appels du noyau
fonctionnel et inversement et le
dialogue pour interconnecter les
couches
PAC (Présenta- Il décompose le logiciel comme C'est un modèle abstrait qui
tion Abstraction une hiérarchie de composants ne décrit pas sous quelle forme
Contrôle) constitué chacun de trois (03) fa- doivent être réalisées et connec-
cettes à savoir : La présentation tées les diérentes facettes
pour la vue, l'abstraction pour
les fonctions à interfacer et le
contrôle qui gère la correspon-
dance entre toutes les facettes
MVC (Modèle Apporte une visibilité claire sur L'inconvénient majeur du modèle
Vue Contrôleur) l'architecture du logiciel. Il sim- MVC n'est visible que dans la réa-
plie les tâches maintenance et lisation de petits projets, de sites
d'amélioration du logiciel. Ainsi internet de faible envergure. En
le logiciel est décomposé en trois eet, la séparation des diérentes
(03) modules à savoir : Le mo- couches nécessite la création de
dèle pour les données à acher, la plus de chiers (3 fois plus exac-
vue pour l'interface graphique et tement) : Un chier pour le mo-
le contrôleur contenant la logique dèle, un chier pour le contrôleur,
concernant les actions eectuées un chier pour la vue
par l'utilisateur.
Table 4.3  tableau de modèle d'architecture

45
 Figure 4.2  Shéma du MVC

4.3 Outils de développement utilisés

Le développement front end est dominé par 3 frameworks : Angular, React
et Vue. Ces frameworks sont évolutifs, exibles et adaptés à la création d'une
grande variété d'applications web.
Dans le cadre de notre travail, nous avons porté le choix sur le framework
Angular
Développé par Google en 2010, Angular est un framework JavaScript open
source qui est actuellement le plus ancien du marché et qui est considéré
comme la meilleure plateforme en matière de développement front.
Basé sur le TypeScript, Angular est considéré comme un framework lourd
et utilisé pour les PC mobiles et de bureau. Il a été développé avec le MVC
(Model-View-Controller), qui comporte des fonctionnalités puissantes per-
mettant aux développeurs de créer des applications riches et à page unique.

Avantage
 Angular est utilisé avec TypeScript et ore un bon support.
 Les services de langage Angular se complètent automatiquement à
l'intérieur des chiers HTML externes du composant.

46
  Aide à la documentation détaillée.
 Structure et architecture spécialement créées pour une meilleure sca-
labilité du projet.
 La fonction de liaison de données unidirectionnelle permet un com-
portement singulier pour le développement d'applications, ce qui mi-
nimise le risque d'erreurs éventuelles.
 Étant le plus ancien framework disponible, Angular bénécie d'un
large soutien de la communauté.

Inconvénient
 Possède diérentes structures comme les composants, les tuyaux, les
injectables et une syntaxe complexe, ce qui rend l'apprentissage di-
cile pour les nouveaux développeurs.
 Moins performant que les deux autres frameworks (React et Vue).

4.3.1 Choix du langage de programmation

Front End
Le développement front end est dominé par 3 frameworks : Angular, React
et Vue. Ces frameworks sont évolutifs, exibles et adaptés à la création d'une
grande variété d'applications web.
Dans le cadre de notre travail, nous avons porté le choix sur le framework
Angular

Figure 4.3  Logo Angular

47
 Développé par Google en 2010, Angular est un framework JavaScript
open source qui est actuellement le plus ancien du marché et qui est consi-
déré comme la meilleure plateforme en matière de développement front.
Basé sur le TypeScript, Angular est considéré comme un framework lourd
et utilisé pour les PC mobiles et de bureau. Il a été développé avec le MVC
(Model-View-Controller), qui comporte des fonctionnalités puissantes per-
mettant aux développeurs de créer des applications riches et à page unique.
Avantage
 Angular est utilisé avec TypeScript et ore un bon support.
 Les services de langage Angular se complètent automatiquement à
l'intérieur des chiers HTML externes du composant.
 Aide à la documentation détaillée.
 Structure et architecture spécialement créées pour une meilleure sca-
labilité du projet.
 La fonction de liaison de données unidirectionnelle permet un com-
portement singulier pour le développement d'applications, ce qui mi-
nimise le risque d'erreurs éventuelles.
 Étant le plus ancien framework disponible, Angular bénécie d'un
large soutien de la communauté.
Inconvénient
 Possède diérentes structures comme les composants, les tuyaux, les
injectables et une syntaxe complexe, ce qui rend l'apprentissage di-
cile pour les nouveaux développeurs.
 Moins performant que les deux autres frameworks (React et Vue).

Back End
Ayant déjà une bonne base typescript grâce au framework angular, nous
avons continuer dans la même lancée avec l'utilisation cette fois du frame-
work NodeJs coté back

48
 Figure 4.4  Logo NodeJs

Avantage
 Le format JSON (JavaScript Object Notation) est le format le plus
utilisé pour l'échange de données. Node.js peut nativement sérialiser
et désérialiser le JSON grâce au fait qu'il utilise JavaScript.
 Le gestionnaire de paquets le plus utilisé : avec Node.js vous allez
utiliser le gestionnaire de paquet npm qui est le plus utilisé au monde.
 Le nombre de librairies open sources modernes est énorme : par exemple
socket.io pour la gestion du temps réel avec l'utilisation notamment
des Websockets.

4.3.2 Choix de l'environnement de développement inté-

gré (EDI)
Au vu de ce qui a été annoncé, nous avons choisi l'utilisation de Visual
Studio pour sa prise en main facile, sa large gamme de langage accepté et
aussi pour la possibilité de rajouter des plugins.

4.3.3 Choix du système de gestion des bases de données

Un système de gestion de base de données (SGBD) est un logiciel système
destiné à stocker et à partager des informations dans une base de données,
en garantissant la qualité, la pérennité et la condentialité des informations,
tout en cachant la complexité des opérations. Il permet d'inscrire, de retrou-
ver, de modier, de trier, de transformer ou d'imprimer les informations de
la base de données. Il permet d'eectuer des comptes-rendus des informa-
tions enregistrées et comporte des mécanismes pour assurer la cohérence des

49
EDI Avantages Inconvénients
Netbeans Gratuit et open source, déve- Auto-complétion incomplète et
loppement et déploiement rapide manque de coloration syntaxique
des applications, supporte bon pour certains langages de pro-
nombre de langage de program- grammations tels qu'AngularJs,
mation et serveurs d'applications PHP
Eclipse Gratuit et open source, grand Plugins instables
éventail de plugins, hautement
modulable, supporte également
un grand nombre de langage, bon
rendu
Visual Studio Gratuit, développement aisé avec Bugs par moment
un grand nombre de langage
IntelijIDEA Développement aisé, achage Payant et ne prend pas tout les
des erreurs à la volée ; auto- langages en compte
complétion intelligente du code
et dédié en grande partie au PHP

Table 4.4  Choix de l'environnement de développement intégré (EDI)

50
informations, éviter des pertes d'informations dues à des pannes, assurer la
condentialité et permettre son utilisation par d'autres logiciels.
Il existe une multitude de SGBD, nous avons une préférence pour le NoSql
qui nous permet d'aller vite dans les développements car il est très modu-
lable. Pour utiliser le langage, nous nous sommes servis de MongoBD

4.4 Méthode de sécurisation des données

4.4.1 Au niveau de la transmission
Dénition du protocole SSL
Conçu par Netscape, SSL est un protocole se plaçant entre la couche
application et la couche transport permettant d'assurer la condentialité,
l'authentication et l'intégrité des données lors des communications. Il peut
être appliqué à des applications comme HTTP, POP, FTP,...

Figure 4.5  Schema SSL

Sécuriser ses échanges par un certicat SSL est maintenant devenu une
nécessité pour bon nombres de services web. Principalement utilisés pour
des sites internet, les certicats SSL protègent également toute application
nécessitant un cryptage des transmissions (transactions bancaires, mails, au-
thentication..).
Le certicat SSL est constitué de :

51
  CSR (Certicate Signing Request) : C'est le chier contenant les in-
formations pour une demande de certicat ;
 KEY : Aussi appelée clé privée, c'est le chier contenant les informa-
tions privées de votre certicat ;
 CRT : C'est le certicat, ce sont les informations publiques du SSL,
par opposition à la clé privée. Il est délivré par une autorité de cer-
tication, ou par le serveur lui-même dans le cas d'un certicat auto
signé.

Principe de fonctionnement
Lorsqu'un utilisateur Internet visite un site web sécurisé, un certicat
SSL fournit des in- formations d'identication concernant le serveur Web et
établit une connexion cryptée. Ce processus prend une fraction de seconde.
 Le client fait une demande de transaction sécurisée au serveur à travers
son navigateur en envoyant sa requête HTTPS ://
 Le serveur lui envoie son certicat d'authentication délivré par une
autorité de certication (Normalement organisme ociel). Ce certi-
cat comporte une clé publique.

Figure 4.6  Schema SSL

 Le navigateur s'assure tout d'abord que le certicat délivré est valide

puis il envoie au serveur une clé secrète codée issue de la clé publique
(De 56 ou 128 bits). Seul le serveur sera donc capable de décoder
cette clé secrète. Cette clé secrète ainsi créée sera utilisée pour encoder

52
 les messages (Cryptographie symétrique). L'algorithme à clé secrète
utilisé (ex : DES, RC4) est négocié entre le serveur et le client.
 Le serveur et le client possède maintenant une clé secrète partagée (La
clé de session) et les échanges sont faits par l'intermédiaire de cette clé.
Pour assurer l'intégrité des données, on utilise un algorithme de hash
(ex : MD5, SHA). S'il y a déconnexion, une nouvelle clé de session
sera négociée.

4.4.2 Au niveau de la reprise d'activité en cas de sinistre

Le reprise d'activité en cas de sinistre consiste à mettre sur pied un plan
d'urgence en cas d'incident majeur (Incendie, séisme). Ainsi pour palier à ce
genre de situation nous proposons :

 L'exportation régulière des données vers un autre emplacement de

stockage ;
 La réplication des données vers d'autres bases de données.

4.5 Architecture de la solution

4.6 Présentation des résultats
Nous vous présentons ici quelques écrans de notre application

53
 Figure 4.7  Schema de l'architecture

Page d'accueil et de connexion

54
 Une fois sur cette page, en cliquant sur le bouton de connexion, on tombe
sur une petite modal qui nous demande nos informations de connexion

Figure 4.9  modal de connexion

Liste des transporteurs

Un transporteur contient ici ses informations personnelles ainsi que les
informations sur les chaueurs et les camions qui sont à sa charge

55
 Figure 4.10  Liste des transporteurs

page d'assignation des AE

Ici assigner une AE revient a lui attribuer un transporteur qui va envoyer
un chaueur et un camion en usine pour venir récupérer la marchandise
(Ciment)

56
 Figure 4.11  Page d'assignation des AE

page d'attribution de Quai

Attribuer un quai a un camion reviens à le mettre dans un espace de
chargement ou il pourra voir son camion être charger et une fois celle-ci faite
il pourra sortir de l'usine et entamé son voyage

57
 Figure 4.12  Page d'attribution des quais

4.6.1 Analyse des résultats

Gain en mobilité
Avec un outil pareil plus besoin de marché dans toute l'industrie avec des
papiers pour valider des autorisations et autres procédures, tout se fait en
ligne

Gain dans la gestion temps réel des activités

Avec notre solution, plus de perde de temps vu que tout est instantané,
il sut juste de disposer d'une connexion internet et tout est joué. L'Appli-
cation se charge de faire le reste pour vous.

58
4.6.2 Limite de la solution
Comme toute ÷uvre scientique, celle-ci ne saurait prétendre être par-
faite. Proposez une solution de gestion et suivi des enlèvements en usine
demande de communiquer avec plusieurs applications interne a l'entreprise,
et ceci limite souvent notre champ d'action surtout niveau maintenance ap-
plicative. L'idéal serait donc de pouvoir avoir un canal qui nous permet de
communiquer de façon directe avec l'ensemble des intervenants externe de
l'application.
Tout au long de ce chapitre, nous avons, fait une étude comparative des outils
nécessaires pour la mise en place de notre solution. Notre étude s'est d'abord
portée sur le choix d'un modèle de processus pour la production de notre
système, ensuite sur le choix des composants et outils technologiques et enn
sur le choix de l'environnement de développement. Au terme d'analyses et
de comparaisons, nous avons identié et choisi un procédé, et des outils ga-
rantissant la production d'un logiciel de qualité. Nous avons ensuite présenté
les résultats de notre implémentation et évalué les gains et limites de celle-ci.

59
Conclusion
Tout au long de la préparation de notre projet de n d'études, nous avons
essayé de mettre en pratique les connaissances acquises durant nos études
universitaires et cela dans le but de réaliser une application de gestion et
suivi des enlèvements en usine.
L'informatique aujourd'hui occupe une place de plus en plus importante dans
le quotidien des entreprises. Face aux dicultés de gestion, il est bien placé
pour venir en aide de la meilleure des manières possibles à l'aide à la décision.
Notre solution FLUID, venu en renfort au département de la logistique sur
les processus d'enlèvement du ciment en usine et au tracking des camions une
fois le ciment sorti jusqu'à la livraison chez le client s'inscrit dans le cadre
la transformation digitale de l'entreprise. L'avantage de notre solution réside
sur le gain en termes de cout, qualité et délai d'exécution des taches.

60