Rapport de stage DTS Ahmadou Yassine Souleymanou.pdf

Stage effectué du 01 Juillet au 30 Septembre 2022 en vue de l’obtention du
Diplôme de Technicien Supérieur option Génie Logiciel
Rédigé par :
Ahmadou Yassine Souleymanou
Etudiant en 2éme année option Génie Logiciel
Sous l’encadrement
République du Cameroun
Paix – Travail – Patrie
Republic of Cameroon
Peace – Work – Fatherland
INSTITUT AFRICAIN D’INFORMATIQUE
Centre d’Excellence Technologique PAUL BIYA
BP : 13179, Yaoundé – Cameroun
Tél : 242 72 99 57 / 242 72 99 58
Site : www.iaicameroun.com
E-mail : contact@iaicameroun.com
SOCIETE DE DEVELOPPEMENT DU COTON DU
CAMEROUN
BP: 302, Garoua – Cameroun
Tél: 222 27 20 80
Fax: 222 27 20 68
E-mail : sodecoton@sodecoton.cm
RAPPORT DE STAGE
CONCEPTION DE LA VERSION MOBILE DE
L’APPLICATION DE GESTION DES MANUTENTIONS
« MANU »
Académique de :
Mme Ada Rihanatou
Chef de centre et enseignante à l’IAI
Garoua
Professionnel de :
M. Ibrahima Hamadou
Chef service Application système et
Bases de données
Année Académique 2021/2022

Ahmadou Yassine Souleymanou | DTS option Génie logiciel | IAI Cameroun 2021/2022
CONCEPTION DE LA VERSION MOBILE DE L’APPLICATION
DE GESTION DES MANUTENTIONS « MANU »
ii

iii
A
Mes parents
DEDICACE

iv
Nous tenons à exprimer notre profonde gratitude à tous ceux qui ont contribué de près ou de
loin à la réalisation de ce document.
Nous tenons tout d’abord à remercier nos chers parents qui ne cessent de nous soutenir, de
nous encourager, et de nous conseiller ;
Nos vifs remerciements à M. Armand Claude ABANDA, Représentant Résidant de l’IAI
Cameroun pour la qualité de l’enseignement qu’il nous consacre
Nous exprimons notre gratitude à l’endroit de :
• M. Mohamadou Bayero, Président Directeur Général de la SODECOTON qui a
bien voulu nous accueillir au sein de son entreprise ;
• M. Ibrahima Hamadou, notre encadreur professionnel pour son accompagnement
continu, tant technique que moral à la réalisation de ce présent travail ;
• Mme Ada Rihanatou, notre encadreur académique pour ses idées, ses conseils
pratiques et ses critiques qui ont été capital pour la réalisation de ce projet ;
• Tout le corps administratif et professoral de l’IAI Cameroun pour l’encadrement et
la qualité de leurs enseignements ;
• M. Moussa Ahmadou, Chef service Application et Digitalisation pour son appui,
ainsi que ses conseils ;
• Tout le personnel de la SODECOTON pour leur accueil chaleureux ;
• Ma famille toute entière, pour leur soutien moral et affectif ;
• Tous mes amis et camarades qui m’ont soutenu directement ou indirectement.
REMERCIEMENTS

v
DEDICACE..............................................................................................................................iii
REMERCIEMENTS...............................................................................................................iv
SOMMAIRE............................................................................................................................. v
LISTE DES TABLEAUX .......................................................................................................vi
LISTE DES FIGURES...........................................................................................................vii
SIGLES ET ABREVIATIONS ..............................................................................................ix
RESUME..................................................................................................................................xi
ABSTRACT ............................................................................................................................xii
INTRODUCTION GENERALE ............................................................................................ 1
DOSSIER D’INSERTION....................................................................................................... 2
I. Accueil et intégration en entreprise................................................................................. 4
II. Présentation de l’entreprise ......................................................................................... 5
III. Organisation de l’entreprise......................................................................................... 9
IV. Plan de localisation.................................................................................................... 11
CAHIER DES CHARGES .................................................................................................... 13
I. Contexte et justification ................................................................................................ 15
II. Objectifs..................................................................................................................... 15
III. Expressions des besoins............................................................................................. 16
IV. Equipe et planning..................................................................................................... 18
V. Estimation du coût du projet...................................................................................... 20
VI. Livrables .................................................................................................................... 23
DOSSIER D’ANALYSE........................................................................................................ 25
I. Analyse de l’existant ..................................................................................................... 27
II. Présentation et justification des méthodologies de travail......................................... 28
V. Présentation des diagrammes..................................................................................... 36
DOSSIER DE CONCEPTION.............................................................................................. 56
I. Objectifs de la conception............................................................................................. 58
II. Présentation des diagrammes intervenants ................................................................ 58
DOSSIER DE REALISATION............................................................................................. 71
I. Equipe de développement et technologies utilisé ......................................................... 73
II. Architecture de déploiement...................................................................................... 78
III. Présentation des diagrammes..................................................................................... 80
GUIDE D’UTILISATION..................................................................................................... 84
I. Guide d’installation....................................................................................................... 86
II. Manuel d’utilisation................................................................................................... 87
CONCLUSION GENERALE ............................................................................................... 95
BIBLIOGRAPHIE................................................................................................................xiii
WEBOGRAPHIE..................................................................................................................xiv
ANNEXES............................................................................................................................... xv
TABLE DES MATIERES ....................................................................................................xvi
SOMMAIRE

vi
Tableau 1: Adresse de l’entreprise............................................................................................. 8
Tableau 2: Equipe de travail..................................................................................................... 18
Tableau 3: Tableau d’ordonnancement.................................................................................... 19
Tableau 4: Ressources matérielles ........................................................................................... 20
Tableau 5: Ressources logicielles ............................................................................................ 21
Tableau 6: Ressources humaines.............................................................................................. 22
Tableau 7: Estimation financière globale................................................................................. 22
Tableau 8: Etude comparative entre MERISE et UML ........................................................... 29
Tableau 9: Différents types de relation dans un diagramme de cas d'utilisation ..................... 39
Tableau 10: Liste des acteurs et leurs rôles dans le système.................................................... 40
Tableau 11: Description textuelle du cas d'utilisation « Enregistrer une manutention ». ........ 43
Tableau 12: Description textuelle du cas d'utilisation « Modifier une manutention »............. 45
Tableau 13: Description textuelle du cas d'utilisation « Editer une facture ». ......................... 47
Tableau 14: Description textuelle du cas d'utilisation « Rechercher une facture ».................. 49
Tableau 15: Formalisme d'un diagramme de séquence............................................................ 50
Tableau 16: Formalisme du diagramme d'activité ................................................................... 59
Tableau 17: Descriptions des relations entre les classes.......................................................... 69
Tableau 18: Equipe de développement .................................................................................... 73
Tableau 19: Technologies logicielles utilisées......................................................................... 74
Tableau 20: Technologies matérielles utilisées........................................................................ 75
Tableau 21: Formalisme du diagramme de déploiement ......................................................... 81
LISTE DES TABLEAUX

vii
Figure 1: Organigramme hierarchique de la SODECOTON ................................................... 10
Figure 2: Plan de localisation................................................................................................... 11
Figure 3: Logo d'UML ............................................................................................................. 30
Figure 4: Genèse de UML........................................................................................................ 31
Figure 5: Illustration du cycle de développement 2TUP.......................................................... 34
Figure 6: Formalisme graphique d'un diagramme de cas d’utilisation .................................... 37
Figure 7: Formalisme d'un acteur en UML .............................................................................. 37
Figure 8: Formalisme d'un cas d'utilisation.............................................................................. 38
Figure 9: Formalisme d'une association................................................................................... 38
Figure 10: Diagramme de cas d'utilisation global.................................................................... 41
Figure 11: Diagramme de cas d'utilisation "Enregistrer une manutention" ............................. 42
Figure 12: Diagramme de cas d'utilisation "Modifier une manutention"................................. 44
Figure 13: Diagramme de cas d’utilisation "Editer une facture" ............................................. 46
Figure 14: Diagramme de cas d'utilisation "Rechercher une facture"...................................... 48
Figure 15: Exemple de diagramme de séquence...................................................................... 51
Figure 16: Diagramme de séquence "S'authentifier" ............................................................... 52
Figure 17:Diagramme de séquence "Enregistrer une manutention" ........................................ 53
Figure 18: Diagramme de séquence "Recherche une facture"................................................. 54
Figure 19: Formalisme d'une classe ......................................................................................... 65
Figure 20: Formalisme d'une association entre deux classes ................................................... 66
Figure 21: Exemple de multiplicité.......................................................................................... 66
Figure 22: Formalisme de l'agrégation..................................................................................... 66
Figure 23: Formalisme de la composition................................................................................ 67
Figure 24: Diagramme de classe .............................................................................................. 68
Figure 25: Exemple de diagramme d'activité........................................................................... 60
Figure 26: Diagramme d'activité "S'authentifier" .................................................................... 61
Figure 27: Diagramme d'activité "Enregistrer une manutention" ............................................ 62
Figure 28: Diagramme d'activité "Modifier une manutention"................................................ 63
Figure 29: Diagramme d'activité "Vérifier une manutention" ................................................. 64
Figure 30: Logo de Java........................................................................................................... 76
Figure 31: Logo de XML ......................................................................................................... 77
Figure 32: Logo de PHP........................................................................................................... 77
Figure 33: Logo de SQL........................................................................................................... 78
Figure 34: Architecture de l'application................................................................................... 80
Figure 35: Diagramme de déploiement.................................................................................... 82
Figure 36: Interface de connexion............................................................................................ 87
Figure 37: Ecran de démarrage ................................................................................................ 87
Figure 38: Interface d'accueil Agent de saisie.......................................................................... 88
Figure 39: Interface d'accueil Vérificateur............................................................................... 89
Figure 40: Interface d'accueil Ordonnateur.............................................................................. 90
LISTE DES FIGURES

viii
Figure 41: Etape 2 "Enregistrer une manutention .................................................................... 91
Figure 42: Etape 3 "Enregistrer une manutention .................................................................... 92
Figure 43: Etape 2 "Verifier une manutention"........................................................................ 93

ix
2TUP: Two Track Unified Process;
API : Application Programming Interface ;
BD : Base de données ;
CPU: Central processing Unit;
CSS : Cascading Style Sheet;
CU : Cas d’utilisation ;
DTS : Diplôme de Technicien Supérieur ;
FTP: File Transfer Protocol;
GHz: Giga Hertz;
GL : Génie Logiciel ;
Go : Giga Octet ;
HTTP : Hypertext Transfer Protocol ;
IAI : Institut Africain d’Informatique ;
IDE : Integrated Développent Environnement ;
IHM : Interface Home Machine ;
JSON : JavaScript Object Notation ;
MERISE : Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise ;
OS: Operating System;
PHP: Hypertext Preprocessor;
RAM: Random Access Memory;
RUP : Rational Unified Process ;
SE : Système d’Exploitation ;
SGBD : Système de Gestion de Base de Données ;
SI : Système d’Information ;
SODECOTON : Société de Développement du Coton du Cameroun
SQL : Structured Query Language ;
SIGLES ET ABREVIATIONS

x
TIC : Technologie de l’Information et de la Communication ;
UML: Unified Modeling Language;
UP: Unified Process;
URL: Uniform Resource Location;
USB: Universal Serial Bus;
OMT: Object Modeling Technique;
OOSE: Object Oriented Software Engineering;
XML : eXtensible Markup Language

xi
En vue de l’obtention du Diplôme de Technicien Supérieur en Informatique option
Génie logiciel, l’Institut Africain d’Informatique préconise pour ses étudiants de deuxième
année, un stage académique de trois mois au sein d’une entreprise. C’est ainsi que nous avons
effectué notre stage à la direction informatique de la SODECOTON, du 01 Juillet au 30
Septembre 2022. Durant cette période, il nous a été attribué pour thème « CONCEPTION
DE LA VERSION MOBILE DE L’APPLICATION DE GESTION DES
MANUTENTIONS MANU ». Pour ce faire, nous avons identifié les besoins et les exigences
des futurs utilisateurs, puis avons établis un cahier de charges qui met en exergue les besoins
fonctionnels et non fonctionnels, l’estimation financière ainsi que la planification du projet.
La mise en place de la solution a nécessité l’utilisation du processus unifié 2TUP basé sur le
langage de modélisation Unified Modeling Language et l’outil ASTAH Professional pour la
réalisation des diagrammes. Les langages de programmation tel que le JAVA, XML, et PHP,
couplés à l’architecture logiciel et l’architecture 3-tiers ont été utilisés pour le déploiement de
la solution. De la réalisation de ce projet, en ressort une application accompagnée d’un cahier
de charges, et de divers dossiers relatant de l’analyse, la conception et du guide utilisation.
Mots clés : Manutention, articles, opération, application mobile.
RESUME

xii
In order to obtain the Diploma of Higher Technician in Computer Science, software
engineering option, the African Institute of Computer Science recommends for its second-
year students, a three-month academic internship within a company. This is how we carried
out our internship at the IT department of SODECOTON, from July 01 to September 30,
2022. During this period, the theme was assigned to us "CONCEPTION OF THE MOBILE
VERSION OF THE HANDLING MANAGEMENT APPLICATION MANU”. To do this,
we identified the needs and requirements of future users, then established specifications that
highlight the functional and non-functional needs, the financial estimate and the project
planning. The implementation of the solution required the use of the unified process 2TUP
based on the modeling language Unified Modeling Language and the ASTAH Professional
tool for the realization of the diagrams. Programming languages such as JAVA, XML, and
PHP, coupled with software architecture and 3-tier architecture were used for the deployment
of the solution. From the realization of this project, an application comes out accompanied by
specifications, and various files relating to the analysis, the conception and the user guide.
Keywords: Handling, article, operation, mobile application
ABSTRACT

Ahmadou Yassine Souleymanou | DTS option Génie logiciel | IAI Cameroun 2021/2022 1
Une application mobile, plus communément appelée « app », est un type de logiciel
d’application conçu pour fonctionner sur un appareil mobile sans fil, tel qu’un smartphone ou
une tablette informatique. Les applications mobiles servent souvent à fournir aux utilisateurs
des services similaires à ceux auxquels ils accèdent sur un ordinateur. De ce fait les
applications mobiles offrent cet avantage d’être utilisables longtemps sans exiger la présence
de l’energie électrique, d’être utilisable où que l’on soit à condition d’être avec son appareil
mobile. C’est dans cette vision que la SODECOTON dans son processus de gestion de
manutention souhaite se doter d’une application mobile pour obtenir une plus grande fluidité
lors de cette gestion. La SODECOTON en nous offrant le privilège d’effectuer notre stage
dans leurs locaux nous a donné l’occasion de faire face à de nombreux problèmes à solution
informatique et relevant de notre formation. Plus largement, ce stage a été l’opportunité pour
nous de prendre connaissance et d’entrer davantage en parfaite symbiose avec les réalités et
les spécificités du travail en entreprise. Au-delà d’enrichir nos connaissances, ce milieu s’est
vue être le cadre idéal pour l’application des notions apprise durant le cycle de formation.
Durant ce stage, la mission qui nous a été confié était la conception de la version mobile de
gestion des manutentions. Dans l’optique de mener à bien notre étude, nous organiserons
notre travail autour de deux principales phases : une phase d’insertion où nous parlerons de
notre structure d’accueil et une phase technique consacrée à la mise en exergue des processus
à suivre pour concevoir et déployer notre plateforme. La phase technique sera alors constituée
de cinq dossiers à savoir le dossier 1 qui nous renseignera sur le cahier de charges du projet ;
le dossier 2 qui portera sur l’analyse du système à mettre en œuvre ; le dossier 3 qui nous
entretiendra sur la conception de notre application ; le dossier 4 qui s’intéressera aux aspects
techniques relatives à la réalisation de la plateforme et le dossier 5 se chargera de présenter le
manuel d’utilisation de la plateforme.
INTRODUCTION GENERALE

Contenu
Introduction
I. Accueil et intégration en entreprise
II. Présentation de l’entreprise
III. Organisation de l’entreprise
IV. Plan de localisation
Conclusion
DOSSIER D’INSERTION
1ère
PARTIE :

Introduction
La phase d’insertion représente la première phase du stage durant laquelle l’étudiant
découvre, se familiarise et recueille les informations concernant l’entreprise dans laquelle il se
trouve.

I. Accueil et intégration en entreprise
1. Accueil
Arrivé le Vendredi 01 Juillet 2022 à 07h23 à la Direction Générale de la SODECOTON,
nous avons été accueillis par Monsieur MOUSSA AHMADOU, Chef de division application
et digitalisation, qui nous a conduit chez Monsieur SOULEYMANOU DEMBA avec lequel
nous avons échangé sur plusieurs points notamment la présentation et le fonctionnement de
l’entreprise, le règlement intérieur de l’entreprise, les objectifs de notre stage ainsi que nos
attentes.
Par la suite, nous avons été redirigés vers notre encadreur Monsieur IBRAHIMA
HAMADOU, Chef service application système et bases de données, avec lequel nous allons
passer le reste de notre stage. A notre arrivé à son bureau, nous avons eu une séance de travail
durant laquelle on a effectué quelques activités à savoir :
• Passage en revue des unités d’enseignement que nous avons eu à effectuer durant
nos deux (02) années de formations ;
• Séance de questions-réponses qui a permis de juger notre niveau et déterminer le
type de programmation qui cadre le plus avec nous ;
• Définition des grandes lignes de notre stage ;
• Planification de nos trois (03) mois de stage.
2. Intégration
Tout au long de notre phase d’insertion qui a durée deux (02) semaines, il était question
pour nous de nous familiariser avec la structure d’accueil tout en nous rapprochant de la haute
hiérarchie ainsi que toute autre personne s’y trouvant et qui de manière directe ou indirecte
pourrait intervenir dans la réalisation de notre projet. Cela a été un moment de joie, de
bonheur mais plus d’apprentissage pour nous car nous côtoyons désormais le monde
professionnel.

II. Présentation de l’entreprise
La SODECOTON, première entreprise dans le Nord Cameroun en termes
d’employabilité, est une structure agro-industrielle spécialisée dans la commercialisation du
coton fibre et de l’huile de table. Pour assurer sa survie et pérenniser son développement, elle
a adopté un mode d’organisation et de fonctionnement adapté à son environnement. Ainsi, il
sera question pour nous dans cette première partie du rapport de présenter d’abord son
historique, ses missions, puis sa situation géographique, ses secteurs d’activités et enfin sa
structure organisationnelle.
1. Historique
En 1913, dans l’optique de développer la culture du coton dans le Nord Cameroun,
l’administration allemande crée à Pitoa près de Garoua un jardin d’essai agricole dirigé par un
botaniste Allemand, le Dr WOLF. Les essais qui y sont effectués et repris par la société du
Lac Tchad et de la Société Cotonnière du Nord Cameroun (SCNC) ne se révèlent pas être
assez concluants. Des chercheurs français dont RENE DUMOND, afin de poursuivre ces
expériences sillonnent le Nord Cameroun dans le but de récolter des informations
indispensables au développement de la culture du coton. Le but atteint entraîne l’installation
de la Compagnie Française du Développement des Fibres Textiles (CFDFT) en 1950 à Kaélé.
Celle-ci va s’intéresser à l’expansion de la culture cotonnière dans la partie septentrionale du
Cameroun à cause des conditions climatiques favorables au développement des plantes
cotonnières, et note à sa première campagne une production de fibre de coton s’élevant à 525
tonnes. La SODECOTON est créée le 10 Mai 1974, suite à la nationalisation des agro-
industriels du Cameroun notamment la CFDFT. A ce jour, c’est une société anonyme
d’économie mixte à participation publique majoritaire dont 70% détenu par l’État du
Cameroun et 30% par la CFDFT, devenue Dagris et aujourd’hui Géo-coton. En 2001, l’état
procède à l’ouverture de son capital, en cédant 11% des parts à la Société d’Investissement du
Cameroun (SIC).

2. Les missions
Ses missions sont entre autres celle de développer la filière coton, renforcer les capacités des
exploitants familiales, achat et transformation du coton produit et généralement le
développement de la zone cotonnière.
C’est ainsi qu’elle se donne la latitude de :
• Vente de la fibre de coton sur le marché intérieur et extérieur ;
• Vente des huiles raffinées, des tourteaux de coton et soja sur le marché intérieur ;
• La production de semences de coton et de soja.
3. Localisation
La SODECOTON couvre presque tout le grand Nord Cameroun. Son siège social
(Direction Générale) était à l’origine à Kaélé. Cependant, elle s’est vue déportée à Garoua
depuis 1979. L’entreprise dans la ville de Garoua est subdivisée en trois structures à des
endroits distincts. Il s’agit de la Direction Générale, de l’huilerie, du parc automobile située
dans la zone industrielle. La SODECOTON compte neuf (09) régions (Maroua1, Maroua1,
Tchatibali, kaélé, Guider, Garoua, Ngong, Mayo-Galké, Touboro). Dans chaque région est
installée au moins une usine d’égrenage dont le rôle est la transformation du coton graine en
coton fibre. Elle compte également deux (02) huileries, la première étant dans la ville de
Garoua et la seconde dans celle de Maroua. Par ailleurs, la SODECOTON est répartie en
quarante-six (46) secteurs agricoles, trois (03) équipes de génie civil basées à Garoua,
Maroua, Touboro et deux cent soixante-seize (276) zones agricoles. En outre, il existe une
délégation de la SODECOTON à Yaoundé, une délégation à Douala, un bureau à
N’Gaoundéré et enfin une correspondance en France.
4. Le Personnel
La SODECOTON compte environ 4000 employés répartis selon les campagnes dans
divers secteurs de travail dans l’entreprise dont :
• Personnel permanent : 1 974
• Personnel saisonnier et temporaires : 3000
5. Activités

Nous avons entre autres plusieurs domaines d’activités à savoir : agricoles, industriels,
commerciales et socioculturels.
a) Activités agricoles
Les activités agricoles de la SODECOTON ont pour but la formation des agriculteurs,
le suivi technique et l’approvisionnement en intrants pour le compte de ces derniers. Par
ailleurs, la SODECOTON ne disposant pas de ses propres plantations de coton, encadre plus
de 350.000 Producteurs de coton et s’occupe de leur suivie. En contrepartie, elle bénéficie du
privilège d’être le seul acheteur du coton de ces planteurs encadrés. La SODECOTON octroie
des crédits pour les cultures de Coton, Soja, Maïs, Sorgho…elle achète le coton et le soja.
b) Activités industrielles
Les différentes transformations s’effectuent entre autres dans les neuf usines
d’égrenages et des deux huileries que possède la SODECOTON. En effet, dès lors que le
coton graine est collecté auprès des producteurs, il est acheminé dans l’une des usines
d’égrenages, où la fibre est séparée de la graine. La fibre qui est le principal produit du coton
est ensuite conditionnée en balle d’environ 200 kg. Après le passage des graines de coton à
l’égrenage, elles sont transportées à huilerie pour l’extraction d’huile raffinée. Il en ressort
une huile brute neutralisée de ces acides gras libres à la soude, qui est décolorée et
désodorisée à température de 170°C pour obtenir l’huile raffinée de table labélisée
DIAMAOR.
c) Activités Commerciales
La SODECOTON est également une compagnie commerciale. Elle commercialise les
produits sortis de ses usines de production. Le marché international absorbe plus de 95% de
coton fibre et une quantité minime, soit 5% est fournie à la Cotonnière Industrielle du
Cameroun (CICAM). De la transformation du coton découlent plusieurs produits bénéfiques
pour les hommes et les animaux d’où leur exploitation et leur commercialisation.
d) Activités sociaux culturelles
La SODECOTON participe au développement de la zone cotonnière par une
contribution à l’amélioration du niveau de vie des paysans producteurs et des autres
partenaires. C’est ainsi qu’elle assure :

• L'assistance technique aux cultivateurs et leur formation, la multiplication et la
fourniture de semences sélectionnées, l'approvisionnement des cultivateurs en
facteurs de production et la récupération de leur coût ;
• L'achat, le stockage et le transport du coton graine, l'égrenage, le classement et
la vente de la fibre aux industries locales ou à l'exportation, et le cas échéant, la
vente de graines ;
• L'exploitation d'huileries en vue de valoriser au mieux la graine de coton. La
vente des produits finis et des sous-produits.
La SODECOTON s’implique aussi bien sur le plan social que sur le plan culturel
camerounais notamment le sponsoring de l’équipe de football COTON SPORT de Garoua ; la
création d’un complexe sportif à Gaschiga.
6. Adresse
Tableau 1: Adresse de l’entreprise
Dénomination
SOCIETE DE DEVELOPPEMENT DU COTON
DU CAMEROUN
Code postal BP 302 GAROUA
Téléphone 222 27 20 80
Fax 222 27 20 68
E-mail sodecoton@sodecoton.cm

III. Organisation de l’entreprise
La SODECOTON est une société anonyme avec un conseil d’administration. Ayant à sa tête
un directeur général assisté d’un directeur général adjoint. La société possède ainsi des
Directions chargées de veiller à la bonne marche de l’entreprise.
1. Organigramme

Figure 1: Organigramme hiérarchique de la SODECOTON

2. Fonctionnement
A la SODECOTON, les journées de travail s’étalent de lundi à vendredi suivant le
découpage horaire ci-dessous :
• De 07h30 à 12h00
• Une pause de 12h à 14h30
• De 14h30 à 18h00
IV. Plan de localisation
Figure 2: Plan de localisation

Conclusion
Durant cette phase d’insertion qui a duré deux (02) semaines à la SODECOTON, nous
avons pu prendre connaissances de ses activités, observer, comprendre et nous familiariser
avec son fonctionnement. Suite à cette phase, en accord avec nos encadreurs académique et
professionnel, le thème « Conception de la version mobile de l’application de gestion de
manutention : MANU ». Dans l’optique de pouvoir évoluer aisément sur ce thème, le
prochain chapitre va porter sur les besoins, les délimitations ainsi que les contraintes dudit
projet.

CAHIER DES CHARGES
2éme
PARTIE :
Contenu
Introduction
I. Contexte et justification
II. Expressions des besoins
III. Equipe et planning
IV. Estimation financière
V. Livrables
Conclusion

Introduction
Le cahier de charge est ce document conçu par le maître d’œuvre et le maître
d’ouvrage. Il devra présenter en détails le projet entre autres les objectifs visés, les besoins du
client ainsi qu’une estimation du coût du projet.

I. Contexte et justification
Nous nous situons ici dans le cadre du stage académique qui permet aux étudiants de
mettre en pratique leurs formations académiques, de consolider leurs connaissances
techniques et de s’initier au marché du travail. C’est ainsi que à notre arrivé à la
SODECOTON, l’entreprise a exprimé le besoin d’implémenter une version mobile d’une
application de bureau déjà existante de gestion des manutentions qui aura pour but d’une part
de faciliter le processus de gestion des manutention et d’autre part de faire face aux
éventuelles pannes électriques.
II. Objectifs
1. Objectif global
L’objectif global de ce projet est d’améliorer la gestion des manutentions et d’optimiser le
processus à travers une application mobile qui devra être fluide avec une interface
ergonomique.
2. Objectifs spécifiques
De manière spécifique, il sera question pour nous de concevoir une application mobile
pouvant :
• Permettre aux agents de saisie, vérificateurs et ordonnateurs de gagner en temps en
réduisant le processus de gestion des manutentions
• Permettre aux agents de saisie, vérificateurs et ordonnateurs d’effectuer leurs
taches même en cas de panne d’électricité
• Permettre à la SODECOTON d’économiser sur l’achat ou le renouvellement des
ordinateurs.

III. Expressions des besoins
L’application à réaliser doit satisfaire les besoins fonctionnels qui constituent les
fonctionnalités que l’application doit offrir et les besoins non fonctionnels qui perfectionnent
l’application.
Ce duo permettra d’obtenir une application complète, fiable avec une ergonomie
conviviale.
1. Besoins fonctionnels
L’application à réaliser doit offrir un ensemble de fonctionnalités qui doivent être
mises en relation avec un ensemble de besoins utilisateur. Ces derniers définissent les services
auxquels les utilisateurs s’attendent à voir fournis par cette application.
La présente plateforme doit satisfaire les besoins fonctionnels suivants :
• La gestion du BackOffice : Le BackOffice est la partie qui permet d’administrer
l’application. Cette partie accessible par l’administrateur intégrera la gestion des
profils d’utilisateurs, la gestion des utilisateurs, la gestion des prestataires, la gestion
des sites, la gestion des articles.
• La gestion de l’authentification avec contrôle d’accès : Notre application doit
authentifier les utilisateurs par un login et un mot de passe pour accéder aux
différentes fonctionnalités et permettre de verifier à partir du login et mot de passe à
quelles fonctionnalités à accès un utilisateur en tenant compte des privilèges
• La gestion des manutentions : Notre application doit permettre à l’agent de saisie
d’enregistrer, modifier et imprimer des fiches manutentions, au vérificateur de verifier
les manutentions et à l’ordonnateur de valider les manutentions. Tous devront
également pouvoir rechercher et consulter la liste des manutentions.
• La gestion de la facturation : Notre application doit permettre à l’ordonnateur de
créer, modifier, imprimer des factures à partir des manutentions enregistrées.

2. Besoins non-fonctionnels
Un besoin non-fonctionnel est une contrainte liée à l’environnement, l’implémentation
et les exigences en matière de performances.
Dans le cadre de ce travail, l'application devra répondre à ces besoins :
✓ La sécurité : Tous les accès des utilisateurs doivent être protégés par un login
et un mot de passe ainsi qu’une gestion de privilèges et de niveaux d’accès
pour les différents types de compte ;
✓ L’intégrité : Garantir l’intégrité et la cohérence des données ;
✓ La performance : Pouvoir supporter des grandes quantités de données et le
temps de réponse des requêtes doit être court ;
✓ La fiabilité : Les données fournies par l'application doivent êtres fiables et
l’application doit rendre des résultats corrects.
✓ Prise en compte de l'expérience de l'utilisateur : Le système doit respecter
le niveau d'expérience de l’utilisateur, donc il doit être simple, compréhensible
et facile à utiliser ;
✓ Respect de la charte graphique : L’interface de notre application doit
respecter la charte graphique de l’entreprise.

IV. Equipe et planning
1. Equipe de travail
Le tableau suivant présente les acteurs de notre projet ainsi que le rôle de chacun.
Tableau 2: Equipe de travail
Acteur Fonction Rôle
SODECOTON Entreprise Maîtrise d’ouvrage (MOA)
IBRAHIMA HAMADOU
Chef service application
système et bases de données
Encadreur professionnel
ADA RIHANATOU
Chef de centre et
enseignante à IAI-Garoua
Encadreur académique
AHMADOU YASSINE
SOULEYMANOU
Elève-Ingénieur en
2éme
année
Maîtrise d’œuvre (MOE)
2. Planning de travail
Un délai de 3 mois nous a été alloué pour la réalisation de notre projet. Ce délai qui nous a
été alloué est insuffisant pour réaliser intégralement le projet, mais raisonnable pour la
réalisation des principales fonctionnalités. La planification de notre projet est représentée dans
le tableau ci-dessous :

Tableau 3: Tableau d’ordonnancement
Phase Objectifs Résultats Durée
Insertion
Prise de contact et
informations sur
l’entreprise
Dossier d’insertion 15 Jours
Analyse
Étude de l’existant et
analyse de la solution
Dossier d’analyse 12 Jours
Conception Conception de la solution Dossier de conception 17 Jours
Réalisation Réalisation de la solution Dossier de réalisation 34 Jours
Test
Test du logiciel et
correction des éventuelles
erreurs
Application mobile 12 Jours
Cet ordonnancement nous a permis de concevoir le diagramme de GANTT suivant :
Figure 3: Diagramme de GANTT (Source: Gantt Project)

V. Estimation du coût du projet
Pour la réalisation de notre application mobile, nous avons évalué les dépenses concernant
l’acquisition des prérequis matériel et logiciels, la rémunération des acteurs pour la bonne
exécution du projet.
1. Ressources matérielles
Le tableau ci-dessous résume les ressources matérielles indispensables pour le
développement de l’application.
Tableau 4: Ressources matérielles
Matériel Rôle Qté P. U (FCFA) P. T (FCFA)
HPE ProLiant
DL380 Gen10
Serveur de stockage des
données
1 2 578 294 2 578 294
4G LTE WIFI
DLINK
Routeur 1 166 750 166 750
APC SRV1KI
BACK UPS 1000 VA
Onduleur – Parafoudre 1 316 250 316 250
HP 27’’ V270 Ecran 1 277 460 277 460
Total ressources matérielles 3 338 754 FCFA
Source : Mercuriale des prix 2022

2. Ressources logicielles
Le tableau suivant regroupe les différentes ressources logicielles dont nous avons
besoin pour mener à bien le projet
Tableau 5: Ressources logicielles
Logiciel Version Editeur Rôle
Prix
(FCFA)
Gantt Project 3.2
Gantt Project
Ink
Outil de
planification
Gratuit
ASTAH Professional 8.5 ChangeVision
Outil de
modélisation
UML
77 841
Android Studio 2.1.16 Google LLC
Environnement de
développement
Gratuit
PHP Storm 2022.1 JetBrains IDE PHP 130 171
XAMPP 8.0.1
Apache
Friends
Mise en place de
serveur local, FTP
Gratuit
Adobe Photoshop 2019 Adobe
Création et
traitement des
images
47 097
Google Chrome 104.0 Google LLC Navigateur web Gratuit
Microsoft Office 2021 Microsoft Suite bureautique 379 245
Microsoft Windows 10 Microsoft
Système
d’exploitation
169 292
Total ressources logicielles 803 646 FCFA
NB : Les prix mentionnés sont issus des sites officiels de leurs éditeurs.

3. Ressources humaines
Le tableau ci-dessous présente les ressources humaines nécessaires et leurs coûts.
Tableau 6: Ressources humaines
Main d’œuvre
Durée
(Jours)
Qté
Honoraire/Jour
(FCFA)
Honoraires total
(FCFA)
Chef de projet 75 1 50 000 3 750 000
Programmeur 63 2 40 000 2 520 000
Testeur 12 2 20 000 240 000
Total ressources humaines 6 510 000 FCFA
4. Coût total du projet
Le tableau suivant le présente l’estimation financière globale pour la réalisation complète de
notre projet :
Tableau 7: Estimation financière globale
Ressource Coût (FCFA)
Ressources matérielles 3 338 754
Ressources logicielles 803 646
Ressources humaines 6 510 000
Imprévus (5% du coût total du projet) 532 620
TOTAL 11 185 020 FCFA

VI. Livrables
A la fin des délais fixés pour la réalisation de notre projet, les éléments qui seront livré à la
maîtrise d’ouvrage sont :
• Un dossier d’analyse
• Un dossier de conception
• Un dossier de réalisation
• Un guide d’utilisation
• Une application mobile sur CD-ROM

Conclusion
En résume, dans cette partie réservée au cahier de charges, nous avons précisé les
objectifs et décrit les attentes de l’entreprise à l’égard de l’application à produire. Nous avons
également évalué les contraintes et ressources nécessaires à la réalisation du projet et établit
un planning à respecter tout au long de notre processus de réalisation. Ainsi, cette partie sera
prise en guise d’introduction au développement proprement parlé de l’application et conduira
à une étape importante du projet, à savoir l’analyse.

DOSSIER D’ANALYSE
3éme
PARTIE :
Contenu
Introduction
I. Analyse de l’existant
II. Présentation et justification de la
méthodologie de travail
III. Présentation des diagrammes
Conclusion

Introduction
Le dossier d’analyse est ce document chargé de ressortir les différentes
caractéristiques de l’existant tant son étude que ses critiques. Il émet et structure par un choix
et une justification de méthode la/les propositions de solutions à apporter à celui-ci pour
l’améliorer de part-les différents diagrammes qui le constitue.

I. Analyse de l’existant
1. Description de l’existant
Dans l’optique de comprendre comment sont gérés les opérations de manutentions sur les
sites de la SODECOTON, nous avons mené une enquête qui nous a conduit à constater
que ces opérations sont gérées par un logiciel propriétaire de la SODECOTON nommé
MANU et dont le processus d’utilisation est le suivant :
• L’agent de saisie qui peut être le magasinier ou agent de saisie de stock enregistre sur
le logiciel la manutention en renseignant la désignation et la quantité demandée, une
fiche lui sera généré ;
• Une fois généré, imprimé et signé, l’agent de saisie remet la fiche au prestataire qui a
son tour va renseigner sur la fiche la quantité effectuée et signe ;
• La fiche sera renvoyée chez le vérificateur qui est l’agent de suivi de stock qui va
vérifier si exactement la quantité effectuée renseigné par le prestataire est correct et
confirme cela sur le logiciel ;
• La manutention est désormais enregistrée et peut être utilisée par l’ordonnateur (chef
de régions, chef d'usine ou chef de division) pour générer une facture.
2. Limites de l’existant
Suite à cette enquête, nous décelons plusieurs limites du système actuel qui sont entre
autres :
• Le fait de devoir noter d’abord les données sur papier avant d’aller les enregistrer dans
le logiciel chose pénible ;
• Le logiciel étant installé sur les ordinateurs de bureau, en cas de panne d’électricité sur
les sites, il sera impossible d’enregistrer les opérations.

3. Propositions de solution
Dans le but de palier aux manquements de l’actuel système observé, nous avons décidé de
concevoir une version mobile Android dudit logiciel, MANU. Cette version pourra être
installé sur tout appareil mobile qui tourne sous le système Android (Smartphone, Tablette,
etc…) et qui présente plusieurs avantages :
• Dispose d’une autonomie permettant de travailler même en cas de panne d’électricité ;
• Facilement portable, il permettra d’enregistrer directement les données sur
l’application immédiatement sur le lieu où sont effectuée les manutentions sans passer
par l’intermédiaire du papier.
D’où découle le thème de notre travail « Conception de la version mobile de l’application
de gestion des manutentions MANU »
II. Présentation et justification des méthodologies de travail
1. Méthode d’analyse
a) Etude comparative
Les premières méthodes d’analyse ont vu le jour dans les années 1970. On compte de
nos jours une diversité de méthodes parmi lesquelles la méthode Booch, Merise, OOSE, les
méthodes basées sur le langage UML. Le tableau suivant présente une analyse comparative
entre deux méthodes que sont Merise et UML.

Tableau 8: Etude comparative entre MERISE et UML
Point de comparaison MERISE UML
Sigles
Méthode d’étude et de
réalisation informatique pour
les systèmes d’entreprise
Unified Modeling Language
Définitions
Méthode d’analyse et de
conception de système
d’information
Langage de représentation
d’un système d’information
Approche
Considère le système réel selon
deux points de vue : un point de
vue statique (les données), un
point de vue dynamique (les
traitements). Il s’agit d’avoir
une vision duale du système
réel pour bénéficier de
l’impression de relief qui en
résulte, et donc consolider et
valider le système final
L’approche objet associe les
informations et les
traitements. De cette façon,
elle assure un certain niveau
de cohérence
Langue Français International
Niveaux d’abstraction
Constitué de 03 niveaux
correspondant à des degrés de
stabilité et d’invariance de
moins en moins élevés. Le
niveau conceptuel, le niveau
physique et logique
Propose différentes notions
(cas d’utilisation, paquetage,
classe, composant, nœud) et
différents diagrammes pour
modéliser le système aux
différents niveaux
d’abstraction
Orientation
Plus adapté à une approche
théorique
Plus orienté vers la
conception

Après cette étude comparative, nous décidons d’adopter UML comme langage de
modélisation puisque nous allons utiliser le concept de l'orienté objet pour développer notre
application mobile de gestion des manutentions MANU.
b) Présentation de UML
Pour développer une application, il ne convient pas de mettre l’accent uniquement sur
l’écriture du code. Il faut d’abord organiser ses idées, les documenter, puis organiser la
réalisation en définissant les modules et les étapes de la réalisation. Cette modélisation
nécessite l’utilisation d’un langage permettant la description du système logiciel ainsi que sa
compréhension par ses futurs utilisateurs. Pour ce faire, nous choisissons UML (Unified
Modeling Language) comme langage de modélisation de notre système car il est langage qui
correspond à la programmation orienté objet.
Le langage UML 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. Il ressemble aux plans utilisés dans d’autres domaines et se compose de
différents types de diagrammes. Dans l’ensemble, les diagrammes UML décrivent la limite, la
structure et le comportement du système et des objets qui s’y trouvent.
Figure 4: Logo d'UML (source : https://fr.wikipedia.org/wiki/UML_(informatique))

UML est né de la fusion des langages de modélisation objet dominant à savoir OMT
de James Rumbauch, BOOCH de Grady Booch et OOSE d’Ivar Jacobson. Ce langage a été
normalisé en janvier 1997 par l’OMG (Object Management Group) qui est une association
américaine crée en 1989 dont l’objectif est de promouvoir et standardiser le modèle objet sous
toutes ses formes.
Il présente de nombreux avantages, à savoir :
• UML est un langage formel et normalisé ;
• UML permet un gain en précision ;
• UML est un support de communication performant ;
• UML facilite la compréhension des représentations abstraites complexes ;
• UML est un langage universel à cause de son caractère polyvalent et sa souplesse ;
• UML est basé sur une démarche itérative et incrémentale qui permet de s’y prendre
plusieurs fois en affirmant son analyse par étapes ;
• UML est piloté par les besoins des utilisateurs.
Comme énoncé plus haut, UML se compose de diagrammes dépendants hiérarchiquement
et qui se complètent de façon à permettre la modélisation d’un projet tout au long de son cycle
de vie. A sa dernière version, la version 2.5, UML compte 14 diagrammes. Ainsi, UML
Figure 5: Genèse de UML (Source https://www.cybermedian.com/fr/a-comprehensive-guide-to-uml-class-diagram/)

définit 9 types de diagrammes dans deux catégories de vues, les vues statiques et les vues
dynamiques.
• Les vues statiques
✓ Le diagramme des cas d’utilisation qui présente les possibilités d'interaction
entre le système et les acteurs (intervenants extérieurs au système), c'est-à-dire
de toutes les fonctionnalités que doit fournir le système ;
✓ Le diagramme de classe qui décrit la structure statique, les types et les
relations des ensembles d’objets ;
✓ Le diagramme d’objet qui décrit les objets d’un système et leurs relations ;
✓ Le diagramme de composants qui décrit les composants physiques du système
d'un point de vue physique, tels qu'ils sont mis en œuvre ;
✓ Le diagramme de déploiement qui présente l'utilisation de l'infrastructure
physique par le système et la manière dont les composants du système sont
répartis.
• Les vues dynamiques
✓ Le diagramme de séquence qui décrit de façon séquentielle le déroulement des
traitements ;
✓ Le diagramme d’activité qui présente les comportements du système ainsi que
ses composants ;
✓ Le diagramme de collaboration qui décrit les messages entre les objets
✓ Le diagramme d’états-transitions qui présente les différents états des objets.

UML est utilisé pour spécifier, visualiser, modifier et construire les documents
nécessaires au bon développement d'un logiciel orienté objet. Dans le cadre d’un projet de
développement logiciel, UML doit être associé à un processus, qui permettra de définir les
différentes étapes de développement. Il peut ainsi être associé à plusieurs processus (RUP,
XUP,2UP…). Dans le cadre de notre projet, nous avons choisi de le lier au processus 2TUP.
2. Processus de développement 2TUP
Le processus unifié (UP : Unified Process) est un processus générique de
développement logiciel mené par UML. Générique signifie car il est nécessaire d’adapter UP
au contexte du projet, de l’équipe, du domaine, et/ou de l’organisation. Parmi les adaptations
on distingue par exemple :
• RUP (Rational Unified Process) ;
• EUP (Enterprise Unified Process) ;
• AUP (Agile Unified Process) ;
• 2TUP (Two Tracks Unified Process).
2TUP est un processus de développement logiciel qui implémente le processus unifié
(c.à.d. itératif, incrémental, basé sur UML). Il propose un cycle de développement qui sépare
les aspects techniques des aspects fonctionnels en partant du constat que toute évolution peut
se traiter parallèlement, suivant un axe fonctionnel et un axe technique. Ensuite, et en
fusionnant les résultats de ces deux axes (branches), on arrive à réaliser le système désiré. Ce
qui nous donne un cycle de développement sous forme de Y. Il commence par une étude
préliminaire qui consiste essentiellement à identifier les acteurs qui vont interagir avec le
système à construire, identifier les messages qu'échangent les acteurs et le système, et à
produire le cahier des charges
La figure ci-dessous présente l’illustration graphique du processus 2TUP :

Figure 6: Illustration du cycle de développement 2TUP (Source : https://www.nassimbahri.ovh/docs/conception/Chapitre-3/)
Le processus 2TUP est ainsi composé de 3 branches à savoir :
• La branche gauche (fonctionnelle) comporte :
✓ La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé
sur le métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un
système inadapté aux utilisateurs. De son côté, la maîtrise d’œuvre consolide les
spécifications et en vérifie la cohérence et l’exhaustivité l’analyse, qui consiste à
étudier précisément la spécification fonctionnelle de manière à obtenir une idée de
ce que va réaliser le système en termes de métier. Les résultats de l’analyse ne
dépendent d’aucune technologie particulière ;
✓ L’analyse, qui consiste à étudier précisément les spécifications fonctionnelles à
obtenir une idée de ce qui va réaliser le système en termes de métier.
• La branche droite (technique) comporte :

✓ La capture des besoins techniques, qui recense toutes les contraintes et les choix
qui circonscrivent la conception du système. Les outils et les matériels
sélectionnés ainsi que la prise en compte de contraintes d’intégration avec
l’existant conditionnent généralement des prérequis d’architecture technique ;
✓ La conception générique, qui définit les composants nécessaires à la construction
de l’architecture technique. Cette conception est la moins dépendante possible des
aspects fonctionnels. Elle a pour objectif d’uniformiser et de réutiliser les mêmes
mécanismes pour tout un système. L’architecture technique construit le squelette
du système informatique et écarte la plupart des risques de niveau technique.
L’importance de sa réussite est telle qu’il est conseillé de réaliser un prototype
pour assurer sa validité.
• La branche du milieu (réalisation) comporte :
✓ La conception préliminaire, qui représente une étape délicate, car elle intègre le
modèle d’analyse fonctionnelle dans l’architecture technique de manière à tracer la
cartographie des composants du système à développer. Cette étape permet de
produire le modèle de conception système. Ce dernier organise le système en
composants, délivrant les services techniques et fonctionnels ;
✓ La conception détaillée, qui permet d’étudier comment réaliser chaque
composant. Cette étape produit le modèle de conception des composants. Il fournit
l’image prête à fabriquer du système complet. La conception détaillée permet de
minimiser l’incapacité de l’architecture technique à répondre aux contraintes
opérationnelles ;
✓ Le codage qui quant à lui permet la production des composants et des tests des
unités de code au fur et à mesure de leurs réalisations
✓ L’étape de recette, qui consiste enfin à valider les fonctions du système
développé

V. Présentation des diagrammes
L’étude fonctionnelle nous a permis de définir les contraintes (ce que notre système doit
réaliser en termes de métier). On y relève ainsi la capture des besoins fonctionnels, d’analyse
et de spécification.
1. Diagramme de cas d’utilisation
a) Présentation
Les diagrammes de cas d’utilisation identifient les fonctionnalités fournies par le
système (cas d’utilisation), les utilisateurs qui interagissent avec le système (acteurs), et les
interactions entre ces derniers. Les cas d’utilisation sont utilisés dans la phase d’analyse pour
définir les besoins de haut niveau du système. Les objectifs principaux des diagrammes des
cas d’utilisation sont :
• Fournir une vue de haut-niveau de ce que fait le système ;
• Identifier les utilisateurs (acteurs) du système ;
• Déterminer des secteurs nécessitant des interfaces hommes-machine (IHM).
Les cas d’utilisation se prolongent au-delà des diagrammes imagés. En fait, des descriptions
textuelles des cas d’utilisation sont souvent employées pour compléter ces derniers et
représentent leurs fonctionnalités plus en détail.

b) Formalisme
Les éléments constitutifs d’un diagramme de cas d’utilisation sont : les acteurs, les cas
d’utilisation, et les associations.
La figure suivante présente de façon graphique le formalisme d’un diagramme de cas
d’utilisation :
i. Acteur
Un acteur est un type stéréotypé représentant une abstraction qui réside juste en dehors
du système à modéliser.
En UML, l’acteur n’est pas nécessairement une personne physique, mais toute entité
(une personne, un service, une société, un système informatique, bases de données, des
équipements…) qui interagit avec le système.
Une même personne physique peut donc être représentée par plusieurs acteurs en
fonction des rôles qu’elle joue. Formellement, un acteur est représenté en UML comme suit :
Nom de l’acteur
ii. Cas d’utilisation
Figure 7: Formalisme graphique d'un diagramme de cas d’utilisation
Figure 8: Formalisme d'un acteur en UML

Un cas d'utilisation représente une fonctionnalité fournie par le système, typiquement
décrite sous la forme Verbe + objet.
Il correspond à un objectif du système, motivé par un besoin d’un ou plusieurs acteurs.
L'ensemble des cas d’utilisation (use cases) décrit les objectifs (le but) du système.
Les cas d'utilisation sont représentés par une ellipse contenant leur nom comme illustré
ci-après :
Nom du cas
iii. Association
Les associations sont utilisées pour lier des acteurs avec des cas d'utilisation. Elles
indiquent qu'un acteur participe au cas d'utilisation sous une forme quelconque. Les
associations sont représentées par une ligne reliant l'acteur et le cas d'utilisation.
Figure 9: Formalisme d'un cas d'utilisation
Figure 10: Formalisme d'une association

iv. Relations
En UML, les acteurs sont liés à leurs différents cas d’utilisation par des diverses
relations qui leur lient. Celles-ci présentent un lien d’association entre ledit acteur et l’action
qu’il mène dans le système. C’est ainsi que l’on distingue les relations suivantes :
Tableau 9: Différents types de relation dans un diagramme de cas d'utilisation
Type de relation Descriptions Représentation graphique
Inclusion
Un cas d’utilisation A inclus un
cas d’utilisation B signifie que
pour effectuer le cas
d’utilisation A, il faut
obligatoirement effectuer le cas
d’utilisation B
Extension
On dit qu’un cas d’utilisation B
étend un cas d’utilisation A si
pendant que l’on effectue le cas
A on a la possibilité d’effectuer
B indépendamment de A
Généralisation
Un cas A est une généralisation
d’un cas B si le cas B est une
autre manière d’effectuer le cas
A (spécialisation).

c) Identification des acteurs et cas d’utilisation
Le tableau suivant présente les différents acteurs de notre système ainsi que les cas
d’utilisations auxquels ils ont accès.
Tableau 10: Liste des acteurs et leurs rôles dans le système
Acteur Rôle
Agent de saisie • Gérer les manutentions
Vérificateur • Verifier les manutention
Ordonnateur
• Gérer les manutentions
• Gérer les factures
Administrateur
• Gérer les comptes d’utilisateurs
• Gérer les sites
• Gérer les articles
• Gérer les prestataires

d) Diagramme de cas d’utilisation global
Figure 11: Diagramme de cas d'utilisation global

e) Diagramme de cas d’utilisation « Enregistrer
une manutention »
Voici le diagramme de cas d’utilisation de « Enregistrer une manutention » :
Figure 12: Diagramme de cas d'utilisation "Enregistrer une manutention"

Tableau 11: Description textuelle du cas d'utilisation « Enregistrer une manutention ».
Présupposé Le système fonctionne correctement
Acteur Agent de saisie
Précondition L’agent de saisie s’est authentifié
Déclencheur L’agent de saisie veut enregistrer une manutention
Scénario
Scénario nominal :
1. L’agent de saisie clique sur le menu « Enregistrer une
manutention »
2. Le système affiche le formulaire d’enregistrement
3. L’agent de saisie remplis le formulaire et clique sur le bouton
« Enregistrer »
4. Le système vérifie les champs du formulaire et enregistre la
manutention
5. Le système génère la fiche de manutention à partir des
informations de l’enregistrement
Scénario alternatif : si les valeurs des champs du formulaire sont
incorrectes (Action 4)
6. Le système envoie un message d’avertissement
7. Le scénario recommence à l’action 2.
Postcondition La manutention est enregistrée

f) Diagramme de cas d’utilisation « Modifier une
manutention »
Voici le diagramme de cas d’utilisation de « Modifier une manutention »
Figure 13: Diagramme de cas d'utilisation "Modifier une manutention"

Tableau 12: Description textuelle du cas d'utilisation « Modifier une manutention ».
Acteur Agent de saisie
Précondition L’agent de saisie s’est authentifié
Déclencheur L’agent de saisie veut modifier une manutention
Scénario
Scénario nominal :
1. L’agent de saisie recherche la manutention qu’il veut modifier
2. L’agent de saisie sélectionne la manutention qu’il veut modifier
et clique sur le bouton « Modifier »
3. Le système affiche le formulaire de modification de la
manutention
4. L’agent de saisie rempli les nouvelles valeurs dans les champs
qu’il veut modifier et clique sur le bouton « Modifier »
5. Le système vérifie les champs
6. Le système effectue la modification
Scénario alternatif : si les valeurs des champs du formulaire de
modification sont incorrectes (Action 5)
8. Le scenario recommence à l’action 3.
Postcondition La manutention est modifiée

g) Diagramme de cas d’utilisation « Editer une
facture »
Voici le diagramme de cas d’utilisation de « Editer une facture » :
Figure 14: Diagramme de cas d’utilisation "Editer une facture"

Tableau 13: Description textuelle du cas d'utilisation « Editer une facture ».
Acteur Ordonnateur
Précondition L’ordonnateur s’est authentifié
Déclencheur L’ordonnateur veut créer une facture
Scénario
Scénario nominal :
1. L’ordonnateur clique sur le bouton « Créer une facture »
2. Le système affiche le formulaire de création de facture
3. L’ordonnateur rempli le formulaire et le clique sur le bouton
« Créer »
4. Le système vérifie les champs
5. Le système effectue la création de la facture
Scénario alternatif : si les valeurs des champs du formulaire sont
incorrectes (Action 4)
7. Le scénario recommence à l’action 3.
Postcondition La facture est créée

h) Diagramme de cas d’utilisation « Rechercher
une facture »
Voici le diagramme de cas d’utilisation de « Recherche une facture » :
Figure 15: Diagramme de cas d'utilisation "Rechercher une facture"

Tableau 14: Description textuelle du cas d'utilisation « Rechercher une facture ».
Acteur Ordonnateur
Précondition L’ordonnateur s’est authentifié
Déclencheur L’ordonnateur veut rechercher une facture
Scénario Scénario nominal :
1. L’ordonnateur clique sur le bouton « Rechercher une
manutention »
2. Le système demande d’entrer un mot-clé pour la recherche
3. L’ordonnateur entre le mot-clé et clique sur le bouton « Entrer »
4. Le système affiche les factures contenant le mot-clé entré
Scénario alternatif : si aucune facture contenant le mot-clé n’a été trouvé
(Action 4)
6. Le scénario recommence à l’action 2
Postcondition Le résultat de la rechercher est obtenue

2. Diagrammes de séquence
a) Présentation
Le diagramme de séquence nous permettre de représenter les interactions entre les utilisateurs
et la plateforme de gestion ainsi que la base de données tout en précisant la chronologie des
échanges de message. Son but principal est de donner une description chronologique sur le
déroulement des cas d’utilisation entre les acteurs et les objets ou objets entre eux.
b) Formalisme
Les éléments constitutifs d’un diagramme de séquence sont : l’objet, l’acteur, la ligne
de vie, l’activation, le message, le cadre du diagramme.
Tableau 15: Formalisme d'un diagramme de séquence
Eléments Descriptions Représentation graphique
Objet
Les objets sont les instances de
classe et sont rangés
horizontalement
Acteur
Un acteur est une personne qui
interagit ou communique avec
le système et les objets
Ligne de vie
La ligne de vie identifie
l’existence de l’objet par
rapport au temps
Activation
L’activation représente
l’ensemble des opérations
exécutées par un objet.
Objet

Message synchrone
Est une communication où
l’émetteur reste en attente de la
réponse à son message avant de
poursuivre ses actions
Message asynchrone
Est une communication où
l’émetteur n’attend pas la
réponse à son message, il
poursuit l’exécution de ses
opérations.
Figure 16: Exemple de diagramme de séquence

c) Diagramme de séquence « S’authentifier »
Figure 17: Diagramme de séquence "S'authentifier"

d) Diagramme de séquence « Enregistrer une manutention
»
Figure 18:Diagramme de séquence "Enregistrer une manutention"

e) Diagramme de séquence « Rechercher une
facture »
Figure 19: Diagramme de séquence "Recherche une facture"

Conclusion
Au terme de cette partie, il était question de faire une analyse détaillée et profonde de
notre projet. Il en ressort que, l’analyse de notre système, en passant par la détermination des
cas d’utilisations nous a permis d’avoir une vision poussée, mais aussi une spécification plus
précise des besoins du client du fait des actions qu’il aura à mener sur la plateforme. Ainsi
elle nous a servi de base à la réflexion sur les mécanismes du système. Le langage de
modélisation et le processus choisis, nous serons utiles par la suite dans l’énoncé du dossier
de conception.

DOSSIER DE CONCEPTION
4éme
PARTIE :
Contenu
Introduction
I. Objectifs de la conception
II. Présentation des diagrammes
intervenants
Conclusion

Introduction
Ce document permet de modéliser dans son ensemble la solution proposée et de
recueillir les informations nécessaires à la mise sur pied d’une base de données complexe et
efficace. De manière globale, il nous offre une vue panoramique sur l’ensemble des éléments
et interactions prise en compte dans le dossier d’analyse.

I. Objectifs de la conception
La conception a pour objectif de permettre de formaliser les étapes préliminaires du
développement d’un système afin de rendre son développement plus fidèle aux besoins du
client. Pour ce faire tout à bord on est parti d’un énoncé informel (tels que les futurs
utilisateurs du logiciel l’on spécifié) ainsi que l’étude et l’analyse de l’existant, la conception
sera donc définie comme la description de l’objet à développer selon une vue interne, cette
partie permet de décrire très simplement le fonctionnement du futur système pour en faciliter
sa réalisation.
II. Présentation des diagrammes intervenants
1. Diagramme d’activité
a) Présentation
Un diagramme d'activités (activités et transitions) est une variante du diagramme
d'états-transitions (états et transitions). Il nous permet de mettre l’accent sur les différents
traitements qui s’exécutent dans notre projet. Il permet de représenter la dynamique de notre
système d’informations et montre les règles d’enchainement des activités entre l’utilisateur, le
système (l’application) et la base de données.
b) Formalisme
Les éléments constitutifs d’un diagramme d’activités sont : les objets, les acteurs, les lignes de
vie, les activations, les messages entre les acteurs et objet ou objet et objet, le cadre du
diagramme.

Tableau 16: Formalisme du diagramme d'activité
Eléments Descriptions Représentation graphique
Etat initial
L’état initial marque le point
d’entrée de la première activité.
Il est représenté par un cercle
plein. Il ne peut qu’y avoir un
seul état initial sur un
diagramme.
Activité
Marque une action faite par un
objet. Il est matérialisé par un
rectangle
Transition
Quand une activité est
accomplie, le traitement passe à
un autre état d’acticité. Les
transitions sont modélisées par
des flèches.
Décision
Représente la fusion des
différents flux, ou une décision
possède au moins deux
embranchements avec le texte
de la condition permettant, aux
utilisateurs de voir les options
Barre de
synchronisation
Associe deux activités
simultanées et les réintroduit
dans un flux ou n’a lieu qu’une
seule activité à la fois
Etat final
Marque la fin d’une activité et
représente l’achèvement de
tous les flux d’un procédé.
Activité 1

Figure 20: Exemple de diagramme d'activité

c) Diagramme d’activité « S’authentifier »
Figure 21: Diagramme d'activité "S'authentifier"

d) Diagramme d’activité « Enregistrer une manutention »
Figure 22: Diagramme d'activité "Enregistrer une manutention"

e) Diagramme d’activité « Modifier une
manutention »
Figure 23: Diagramme d'activité "Modifier une manutention"

f) Diagramme d’activité « Vérifier une
manutention »
Figure 24: Diagramme d'activité "Vérifier une manutention"

2. Diagramme de classe
Le diagramme de classe exprime la structure statique du système en termes de classes et
de relations entre ces classes. L’intérêt du diagramme de classe est de modéliser les entités du
SI. Le diagramme de classe permet de représenter l’ensemble des informations finalisées qui
sont gérées par système.
a) Formalisme
Les principaux éléments de ce diagramme sont : les classes, et leurs associations (association,
généralisation, agrégation, composition, dépendance). Sa description se fonde sur les attributs,
les opérations d’une classe, et les différents types d’associations entre classes.
Nous pouvons décrire ces éléments comme suit :
• Classe : Une classe décrit un groupe d’objets ayant les mêmes propriétés (attributs),
un même comportement (opérations), et une sémantique commune (domaine de
définition).
• Attribut : Un attribut est une propriété élémentaire d’une classe. Pour chaque objet
d’une classe, l’attribut prend une valeur (sauf cas d’attributs multivalués).
• Opération : Une opération est une fonction applicable aux objets d’une classe. Une
opération permet de décrire le comportement d’un objet. Une méthode est
l’implémentation d’une opération.
Figure 25: Formalisme d'une classe

• Association : Une association entre classes représente les liens qui existent entre les
instances de ces classes.
• Multiplicité : La multiplicité indique un domaine de valeurs pour préciser le nombre
d’instance d’une classe vis-à-vis d’une autre classe pour une association donnée. La
multiplicité peut aussi être utilisée pour d’autres usages comme par exemple un
attribut multivalué.
• Agrégation : L’agrégation est une association qui permet de représenter un lien de
type « ensemble » comprenant des « éléments ». Il s’agit d’une relation entre une
classe représentant le niveau « ensemble » et 1 à n classes de niveau « éléments »
Figure 26: Formalisme d'une association entre deux classes
Figure 27: Exemple de multiplicité
Figure 28: Formalisme de l'agrégation

• Composition : La composition est une relation d’agrégation dans laquelle il existe une
contrainte de durée de vie entre la classe « composant » et la ou les classes « composé
». Autrement dit la suppression de la classe « composé » implique la suppression de la
ou des classes « composant ».
Figure 29: Formalisme de la composition

b) Diagramme de classe du système
Figure 30: Diagramme de classe

c) Règles de gestion
Les relations entre les classes nous permettent de ressortir un diagramme de classe
plus ou moins complet. Elles sont tirées de l’expression des besoins. Nous avons donc les
relations suivantes :
Tableau 17: Descriptions des relations entre les classes
Relations Description
RG1 Une manutention comporte au moins un détail de manutention
RG2 Une manutention est effectuée par un seul prestataire
RG3 Une manutention est effectuée au cours d’un seul exercice
RG4 Une manutention constitue un détail de facture
RG5 Une manutention est constituée d’une ou plusieurs opérations
RG6 Une opération appartient à une seule catégorie d’opération
RG7 Une opération est effectuée par un seul prestataire
RG8 Une opération est effectuée pour plusieurs détails de manutention
RG9 Une facture est adressée à un seul prestataire
RG10 Une facture est établie durant un seul exercice
RG11 Une facture comporte au moins un détail de facture
RG12 Un prestataire effectue plusieurs manutentions

Conclusion
Le dossier de conception nous a permis de faire une analyse approfondie, de ressortir
les données validées et les traitements à automatiser et nous offre tous les outils nécessaires
pour une bonne réalisation. La branche technique se situe dans le processus de modélisation,
un maillon important qui permet de définir et de spécifier les différents éléments
architecturaux constituant l’application ou le système d’information étudié. Dans le dossier
qui suivra, il sera question de dénombrer les solutions nous permettant de mettre en exergue
l’architecture logicielle, matérielle et physique dudit système.

DOSSIER DE REALISATION
5éme
PARTIE :
Contenu
Introduction
I. Equipe et technologies utilisées
II. Architecture de déploiement
intervenants
Conclusion

Introduction
Le dossier de conception influence considérablement le dossier de réalisation ceci dans
la mesure où il offre tous les outils nécessaires pour une bonne réalisation. Le maillon
important dans cette chaine est la branche de réalisation. Elle permet de produire de façon
concrète les objets issus de la branche technique. Il sera question pour nous tout au long de
cette phase de mettre en exergue l’architecture logicielle, physique et matérielle dudit
système, à travers les diagrammes tels que celui de composant, de déploiement, le modèle
physique et l’architecture du code.

I. Equipe de développement et technologies utilisées
1. Equipe de développement
Pour la réalisation de notre projet, les personnes suivantes y ont participé :
Tableau 18: Equipe de développement
Acteur Fonction Rôle
SODECOTON Enterprise Maître d’ouvrage
M. Ibrahima Hamadou
Chef service Application
système et Bases de données
Encadreur professionnel
M. Ahmadou Yassine
Souleymanou
Elève-Ingénieur en 2e
année
Chargé de l’exécution du
projet
2. Technologies logicielles
Dans le cadre de la réalisation de notre projet, nous avons décidé d’utiliser les logiciels
présentés dans le tableau ci-dessous :

Tableau 19: Technologies logicielles utilisées
Logo Nom du logiciel Rôle
Android Studio Environnement de
développement
PhpStorm IDE PHP
XAMPP Server Serveur local
Google Chrome Navigateur web
Adobe Photoshop
Création et traitement des
images

3. Technologies matérielles
Pour la réalisation de notre projet, nous avons utilisés les matériels suivants :
Tableau 20: Technologies matérielles utilisées
Matériel Caractéristiques
Ordinateur portable
Marque : DELL Latitude E5570
RAM : 8 Go
CPU : INTEL Core i5 2.5 GHz
DD : 500 Go
Telephone android
Marque : TECNO Spark 3 Pro
RAM : 2 Go
DD : 32 Go
Modem Wi-Fi
Marque : BVOT M81
Type de réseau : 4G
Opérateur : Orange
4. Langages de programmation
Pour la mise sur pied de notre application et selon les besoins des utilisateurs finaux, le
langage de programmation retenu est le JAVA. À ce langage, nous allons associer le XML,
PHP, et le SQL. Chacun de ces langages sera présenté de façon détaillée dans les paragraphes
qui suivront.

a) Le JAVA
Le JAVA est un langage de programmation orienté objet créé par James Gosling et
Patrick Naughton, employés de Sun Microsystems, avec le soutien de Bill Joy (cofondateur de
Sun Microsystems en 1982) présenté officiellement le 23 mai 1995. La société Sun a été
ensuite rachetée en 2009 par la société Oracle qui détient et maintient désormais Java.
Java est un langage de programmation à usage général, évolué et orienté objet dont la
syntaxe est proche du C. Ses caractéristiques ainsi que la richesse de son écosystème et de sa
communauté lui ont permis d'être très largement utilisé pour le développement d'applications
de types très disparates. Java est notamment largement utilisé pour le développement
d'applications d'entreprises et mobiles.
Figure 31: Logo de Java

b) Le XML
L'eXtensible Markup Language, généralement appelé XML, « Langage de balisage
extensible » en français, est un métalangage informatique de balisage générique conçu par
Tim Bray, Jon Bosak et de nombreux autres collaborateurs, entre 1996 et 1999.
C’est un sous-ensemble du Standard Generalized Markup Language (SGML). Sa
syntaxe est dite « extensible » car elle permet de définir différents langages avec pour chacun
son vocabulaire et sa grammaire.
c) Le PHP
Le Hypertext Preprocessor, plus connu sous son sigle PHP, est un langage de
programmation libre créé en 1994 par Rasmus Lerdorf, principalement utilisé pour produire
des pages Web dynamiques via un serveur HTTP. PHP est un langage impératif orienté objet.
Il s'agit d'un langage de script interprété côté serveur.
Il est considéré comme une des bases de la création de sites web dits dynamiques mais
également des applications web. PHP a permis de créer un grand nombre de sites web
célèbres, comme Facebook, Wikipédia, etc.
Figure 32: Logo de XML
Figure 33: Logo de PHP

d) Le SQL
SQL pour Structured Query Language, en français langage de requête structurée est
un langage informatique normalisé servant à exploiter des bases de données relationnelles. La
partie langage de manipulation des données de SQL permet de rechercher, d'ajouter, de
modifier ou de supprimer des données dans les bases de données relationnelles.
II. Architecture de déploiement
Pour avoir une architecture évolutive, robuste et modulable, il nous faut utiliser une
architecture basée sur le système dit de « couche ». Nous allons donc séparer au maximum les
différents types de traitements de l’application (présentation, métier, accès aux données). Ceci
correspond à une architecture 3-tiers.
Dans cette approche, les couches communiquent entre elles et chacune propose un
ensemble de service. Les services d’une couche sont mis à la disposition de la couche
supérieure. On empêche donc qu’une couche invoque les services d’une couche plus basse
que la couche immédiatement inférieure ou plus haute que la couche immédiatement
supérieure. Le rôle de chaque couche étant bien défini, les fonctionnalités de l’une peuvent
évoluer sans impliquer des changements dans les autres. Il s’agit donc d’un modèle logique
d’architecture applicative qui vise à modéliser une application comme un empilement d trois
couches logicielles dont le rôle est clairement défini :
Figure 34: Logo de SQL

1. Couche de présentation (Premier niveau)
Correspond à l’affichage, la restitution sur les appareils clients, le dialogue avec les
utilisateurs. On parle d’interface Homme-machine. Cette interface peut prendre multiples
facettes, sans pour autant changer la finalité de l’application. La couche présentation relaie les
requêtes de l’utilisateur à destination de la courbe métier et en retour lui présente les
informations renvoyées par les traitements de cette couche.
2. Couche de traitement (Deuxième niveau)
Correspond à la mise en œuvre de l’ensemble des règles de gestion et de la logique
applicative. C’est la partie fonctionnelle de l’application, celle qui implémente la logique et
qui décrit les opérations que l’application opère sur les données en fonction des requêtes des
utilisateurs, effectués au travers de la couche présentation. Les différentes règles de gestion et
de contrôle du système sont mises en œuvre dans cette couche. La courbe métier offre des
services applicatifs et métiers à la couche présentation. Pour fournir ces services, elle s’appuie
sur les données du système accessibles au travers des services de la couche inférieure. En
retour, elle renvoie à la couche présentation les résultats qu’elle a calculés.
3. Couche d’accès aux données (Troisième niveau)
Correspond aux données qui sont destinées à être conservées sur une durée finir voire
même infinie. C’est la partie qui gère l’accès aux données du système. Ces données peuvent
être propres au systèmes ou gérées par un autre système. La courbe métier n’a pas à s’adapter
à ces deux cas, ils sont transparents pour elle car l’accès aux données se fait de manière
uniforme.

Dans le cas de notre application, la première couche qui est la présentation est assuré
par la plateforme Android ; La seconde couche qui est le traitement par le web service PHP ;
et la troisième couche par le serveur de base de données MySQL.
C’est ainsi que donc que l’architecture de notre application se présente de la manière
suivante :
1. Diagramme de déploiement
Le diagramme de déploiement est une vue statique qui sert à représenter l’utilisation
de l’infrastructure physique par le système et la manière dont les composants du système sont
repartis ainsi que les relations entre eux. Le diagramme de déploiement se rapproche de la
réalité physique puisqu’il identifie les éléments matériels, leur disposition physique et la
disposition des composants sur ces éléments matériels. Le diagramme de déploiement permet
donc de représenter l’architecture physique d’un système.
Application
Android
Web service
PHP
Base de données
MySQL
Figure 35: Architecture de l'application

Rapport de stage DTS Ahmadou Yassine Souleymanou.pdf

Rapport de stage DTS Ahmadou Yassine Souleymanou.pdf

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Rapport de stage DTS Ahmadou Yassine Souleymanou.pdf

Similaire à Rapport de stage DTS Ahmadou Yassine Souleymanou.pdf (20)

Rapport de stage DTS Ahmadou Yassine Souleymanou.pdf