Final Rapport

REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON
PAIX-TRAVAIL-PATRIE PEACE-WORK-FATHERLAND
MINISTERE DE L’ENSEIGNEMENT MINISTRY OF HIGHER EDUCATION

SUPERIEUR
INSTITUT UNIVERSITAIRE SAINT JEROME CATHOLIC

CATHOLIQUE UNIVERSITY INSTITUTE OF DOUALA
SAINT-JÉRÔME DE DOUALA
SAINT- JÉRÔME POLYTECHNIQUE

SAINT JEROME POLYTECHNIC
(Git -Sjp 3)
RAPPORT DE STAGE
CONCEPTION ET REALISATION D’UNE APPLICATION MOBILE

D’ARCHIVAGE DES RAPPORTS ET MEMOIRES AU SEIN DE LA
CATHO SAINT JEROME DE DOUALA
Par MOMO KEUDEM AUDREY NATACHA
Stage Numéro : 20-SJP2-LT-012-01
Effectué au sein de l’entreprise :
CIC
Encadré par :
Mme Sombsi Adèle Mme Sombsi Adèle
Responsable Responsable
(Tuteur Académique) (Tuteur Entreprise)
Année Académique 2019-2020
2
DEDICACE
Je dédie ce travail à mes parents, ma mère qui ne cesse de me soutenir et mon père qui est toujours à mes
côtés et ne cesse de m’encourager.
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE II

2
REMERCIEMENTS
Qu’il me soit permis ici d’avouer ma reconnaissance et mon respect envers ceux qui ont eu la
bonne volonté de me motiver et me soutenir vers la quête de l’excellence. Ainsi, je m’incline
 Tout d’abord devant le Dieu tout puissant pour m’avoir accordé les moyens physiques
et spirituels me permettant de vivre cette expérience.
 Aussi je remercie l’Administrateur Général de SAINT JEROME DE DOUALA pour
le plus qu’il nous accorde pour notre formation.
 J’adresse mes vifs remerciements à mon encadreur, Mme Sombsi Adèle, au poste de
responsable des serveurs pour son entière disponibilité, son aide inestimable et ses
conseils, sans lesquels ce travail n’aurait pas abouti.
 Aussi, je remercie très humblement la direction informatique notamment Mr
Tekinzang et Mr Mfongourain pendant toute la période de mon stage.
 Je ne saurais terminer sans témoigner mes remercie assez les membres du jury pour
leur disponibilité, leurs précieux conseils et remarques constructives.
 Enfin, je tiens à remercier tous mes frères et sœurs, pour leur amour leurs conseils et
leur soutien au quotidien.
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE III

2
TABLE DES FIGURES

Figure 3-1Illustration du processus 2TUP................................................................................30
Figure 3-2: Illustration d'un acteur............................................................................................30
Figure 3-3..................................................................................................................................30
Figure 3-4 Illustration d'un cas d'utilisation..............................................................................31
Figure 3-5: Tableau des acturs de notre système......................................................................31
Figure 3-6: Illustration du diagramme des cas d'utilisation d'un visiteur.................................32
Figure 3-7: Illustration du cas d'utilisation d'un étudiant..........................................................33
Figure 3-8: Illustration du cas d'utilisation de l'administrateur.................................................33
Figure 3-9: Illustration de l’architecture MVC.........................................................................44
Figure 4-1: les couleurs de l'application...................................................................................46
Figure 4-2: logo du HTML 5....................................................................................................46
Figure 4-3: Logo du Visual Studio Code..................................................................................47
Figure 4-4: Logo de Node js.....................................................................................................47
Figure 4-5: Logo de Google......................................................................................................47
Figure 4-6: Logo de SQLite......................................................................................................48
Figure 4-7: Logo de Firebase....................................................................................................48
Figure 4-8: Logo de DB BROWSER for SQLite.....................................................................49
Figure 4-9: Logo d'EdrawMax..................................................................................................49
Figure 4-10: Logo d'Ionic.........................................................................................................49
Figure 4-11: Architecture d'une application Ionic....................................................................50
Figure 4-12: Logo de d'Apache Cordova..................................................................................50
Figure 4-13: Logo d'Angular JS................................................................................................51
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE IV

2
LISTE DES TABLEAUX

Tableau 1-2: Fiche signalétique de l'entreprise.........................................................................17
Tableau 2-1 : Etudue compartaive de la durée de vie de quellques supports technologique....23
Tableau 2-2 : Fonctionnalités d'un SAE...................................................................................24
Tableau 3-1 : Diagrammes utilisés dans notre travail...............................................................28
Tableau 3-2: Tableau de l'ensemble des cas d'utilisation de notre système..............................34
Tableau 3-3: Description détaillée du cas d'utilisation "S'authentifier"....................................34
Tableau 3-4: Description détaillée du cas d'utilisation « Ajout des comptes ».......................35
Tableau 3-5: Description détaillée du cas d'utilisation « Ajouter des documents ».................36
Tableau 3-6: Description détaillée du cas d'utilisation «Modification des documents »..........37
Tableau 3-7: Description détaillée du cas d’utilisation « Supprimer des documents »............38
Tableau 3-8: Description du cas d'utilisation « consulter des mémoires en fonction des
écoles »......................................................................................................................................39
Tableau 3-9: Description détailllée du cas d'utilisation « Effectuer une recherche»................40
Tableau 3-10: Description détaillée du cas d'utilisation « Afficher les informations d'un
mémoire ».................................................................................................................................41
Tableau 3-11: Description détaillée du cas d’utilisation « Télécharger les supports numériques
des mémoires»..........................................................................................................................41
Tableau 4-1 Description du projet............................................................................................45
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE V

2
LISTE DES ABBREVIATIONS

API : Application Programming Inteface
APK : Android Package
ASCII : American Standard for Information Interchange
CSS : Cascading Style Sheets
DOM : Document Objet Model
HTML : Hypertext Markup Language
Ios : Iphone Operating Système
MVC : Modele-Vue-Controleur
SAE : Système d’Archivage Electronique
UML : Unified Modeling Language
2TUP :2Track Unified Language
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE VI

2
TABLES DE MATIERES
DEDICACE................................................................................................................................II
REMERCIEMENTS.................................................................................................................III
TABLE DES FIGURES...........................................................................................................IV
LISTE DES TABLEAUX..........................................................................................................V
LISTE DES ABBREVIATIONS..............................................................................................VI
TABLES DE MATIERES.......................................................................................................VII
RESUME..................................................................................................................................IX
ABSTRACT...............................................................................................................................X
INTRODUCTION GENERALE................................................................................................1
Chapitre 1 : Aperçu général et cadre du projet.....................................................................2
1.1 Présentation de l’entreprise..........................................................................................2
1.1.1 Historique et évolution.............................................................................................2
1.1.2 Les objectifs de la Catho Saint-Jérôme....................................................................3
1.1.3 Structure organisationnelle......................................................................................4
1.1.4 Situation géographique............................................................................................5
1.2 Description du service dans lequel...............................................................................5
1.3 Présentation du projet...................................................................................................5
1.3.1 Contexte et problématique.......................................................................................5
1.3.2 Objectifs du projet....................................................................................................6
1.3.3 Méthodologie...........................................................................................................6
1.3.4 Contraintes du projet................................................................................................7
Chapitre 2 REVUE DE LITTERATURE.............................................................................9
2.1 Etat de l’art de l’archivage numérique.........................................................................9
2.1.1 Définition et Objectifs..............................................................................................9
2.1.2 La problématique...................................................................................................10
2.1.3 Fonctionnalités.......................................................................................................11
2.2 Normes concernées par l’archivage numériques........................................................12
2.2.1 La norme 19005(2005, révisée en 2011 et 2012)...................................................12
2.2.2 OAIS (Is 1472 : 2012) (2012, révisée en 2012).....................................................12
Chapitre 3 METHODOLOGIE ET APPROCHE ADOPTEE............................................12
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE VII

2
3.1 Etude comparative de MERISE et UML....................................................................12

3.2 Présentation de l’UML...............................................................................................13
3.2.1 Les avantages de l’UML........................................................................................14
3.2.2 Les limites de l’UML.............................................................................................14
3.2.3 Le 2TUP ( Two Track Unified Process)................................................................15
3.3 Modélisation des différents diagrammes UML..........................................................16
3.3.1 Le diagramme des cas d’utilisation........................................................................16
3.3.2 Diagramme de classe.............................................................................................27
3.4 L’architecture MVC...................................................................................................28
3.4.1 Présentation............................................................................................................28
3.4.2 Composition de l’architecture MVC......................................................................28
3.4.3 Avantages du modèle MVC...................................................................................29
Chapitre 4 : Résultats et discussion....................................................................................30
4.1 Conception graphique................................................................................................30
4.1.1 Synopsis.................................................................................................................30
4.2 Outils..........................................................................................................................32
4.2.1 Choix technique.....................................................................................................32
4.3 Les fonctionnalités développées.................................................................................37
4.3.1 Présentation de l’interface de l’application............................................................37
4.3.2 Présentation de l’interface d’authentification........................................................37
4.3.3 Présentation de l’interface de l’espace utilisateur..................................................37
4.3.4 Interface de l’espace étudiant.................................................................................37
4.3.5 Présentation de l’interface de gestion des comptes................................................37
4.3.6 interfac...................................................................................................................37
4.3.7 Présentation de l’interface de consultation des mémoires.....................................37
Conclusion Générale.................................................................................................................38
REFERENCES BIBLIOGRAPHIQUES..................................................................................XI
WEBTOGRAPHIE...................................................................................................................XI
ANNEXES DIAGRAMMES DES CAS D’’UTILISATION................................................XIII
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE VIII

2
RESUME
Ce rapport s’inscrit dans le cadre de la réalisation de la conception et réalisation d’une
application mobile pour la gestion des archives des rapports et mémoires des étudiants de la
catho Saint Jérôme de Douala. Cette application a été dans le dessein de pouvoir gérer
l’ensemble des rapports et mémoires des étudiants afin de faciliter les taches d’administration.
Ainsi notre objectif est donc de pouvoir mettre à disposition des étudiants une plateforme
permettant de consulter, de télécharger les mémoires et rapports répertoriés dans le système.
Afin de pour pouvoir atteindre cet objectif nous avons créé une application mobile
multiplateforme modélisée à partir du langage UML (Unified Modeling Language). La
réalisation quant à elle a fait appel à de nombreux outils de développement bien adaptés au
contexte de notre application. Le langage de programmation que nous avons utilisé est le
TypeScript. Quant aux bases de données l’utilisation de Firebase et de SQLite nous a été
indispensable.
Mots clés : Application mobile, Archivage électronique, XML, Ionic
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE IX

2
ABSTRACT
This report is part of the realization of a mobile application for the management of archives of
the reports and memoirs of tthe students of the University Institute Saint Jerome of Douala.
This application was designed to manage all the reports and dissertations of students to
facilitate the tasks of administration. Thus, our goal is to provide students with a platform to
consult, download, listed in the system. In order to achievethis goal, we have created a coss-
platform mobile application modeled from the UML (Unified Modeling Language). The
realization of the application used many development tools well adapted to the context of our
application. We used tthe Ionic framework based on the TypeScript. An for the Databases the
uses of Firebase and SQLite was essantial.
Key Words: Mobile applicatuion, electronic archives, Ionic.
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE X

2
INTRODUCTION GENERALE
Les Smartphones ont connu un essor très important au cours de ces dernières années. Ils sont
de plus en plus dotés de puissance avec des fonctionnalités assez évoluées permettant de créer
des applications innovantes et de les distribuer en toute simplicité. Bien plus que des appareils
nous permettant d’effectuer des appels ou d’envoyer des SMS, ces terminaux sont devenus de
véritables outils multimédia permettant de répondre efficacement aux besoins de ces
utilisateurs.
La Catho Saint Jérôme de Douala a décidé d’oriente une grande partie de ses activités vers le
développement de solutions mobiles complètes et innovantes pour afin de satisfaire ses
besoins par la mise à disposition des services basiques accessibles depuis un terminal. C’est
dans ce cadre que nous avons été accueilli par cette structure comme stagiaire pendant une
période de 03 mois pour travailler sur un de ces nombreux projets de développement mobiles
sous le thème du « développement d’une application mobile d’archivage numérique des
rapports et mémoires des étudiants ». Cette solution qui sera développée fonctionnera sur
toutes les plateformes mobiles et permettra à ses utilisateurs de consulter les rapports de stage
des étudiants de la Catho Saint Jérôme de Douala.
Nous allons donc détailler le projet dans ce rapport sur quatre grandes articulations. Le
premier chapitre sera une présentation générale du cadre du projet et de et de l’entreprise
d’accueil dans lequel nous présenterons Saint–Jérôme au travers de sa fiche signalétique et de
ses missions. Le deuxième chapitre sera réservé à la présentation de l’état de l’art qui est une
revue de littérature portant sur l’archivage numérique, ensuite nous consacrerons le troisième
chapitre à la méthodologie et la conception de notre application. Enfin, le dernier chapitre sera
dédié à la réalisation et la présentation du travail.
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page 1

2
Chapitre 1 : Aperçu général et cadre du projet

1.1 Présentation de l’entreprise
Une entreprise se définit comme une unité économiquement, juridiquement autonome dont la
fonction principale est de produire des biens et des services à destination des personnes
physiques et/ ou morales afin d’en tirer bénéfice. Dans ce chapitre, il sera question pour nous
de présenter dans un premier temps la Catho SAINT JEROME DE DOUALA, l’organisme au
sein duquel nous avons effectué notre stage. Nous présenterons tour à tour son historique son
évolution et son organigramme. Ensuite nous présenterons notre projet en abordant la
problématique et l méthodologie adoptée.
1.1.1 Historique et évolution

L’Institut Catholique Saint-Jérôme de Douala est un établissement privé d’enseignement
supérieur basé à Douala. Elle a été mise sur pied en septembre 2009 par Mgr Samuel Kleda
dans l’idée de former les ingénieurs et les managers dans des domaines correspondant aux
besoins locaux immédiats. Son slogan est un étudiant = un emploi. Par son nom de baptême,
l’Institut entend incarner des valeurs au service du savoir pour l’épanouissement intégral des
étudiants.
Les dates marquantes de l’histoire de la Catho Saint-Jérôme de Douala sont pour la plus part
les suivantes :
 Le 23 Septembre 2009, la Catho Saint-Jérôme de Douala obtient pour l’autorisation

provisoire N°020090010 /N/MINESUP/DDES/ELSPSAC/ebm.
 Le mois d’octobre 2010 a été marquée par la création de l’Institut Supérieure des
Sciences Religieuses et Sociales (IRRS) et de l’Institut Supérieure des Sciences
Appliquée (ISGA) reconvertie en Saint-Jérôme Business School (SJMB).
 L’arrêté de création N°12 /0364 /MINESUP / du 16 aout 2012 accordé à
l’Archidiocèse de Douala représenté par Mgr Samuel Kleda.
 L’école d’ingénieurs voit le jour en Septembre 2012 sous la dénomination de Saint-
Jérôme (SJP).
 Enfin, en juillet 2014, l’arrêté N°14/0389/MINESUP/SG/DDES du 04 Juillet 2014
autorise l’ouverture de l’institut Catholique Saint-Jérôme de Douala
Le tableau suivant présente la fiche signalétique de l’entreprise.

2
Tableau 1-1: Fiche signalétique de l'entreprise
Dénomination Sociale Université Catholique Saint-Jérôme de

Douala
Forme juridique Etablissement d’enseignement privé
Sigle IUCSJD
Année de création 2009
Slogan Un étudiant = un emploi
Boite Postal P0 BOX 5949
Téléphone +237
Fax +237 233 42 21 47 / +237 233 42 21 49
Email infos@univ-catho-sjd.com / www.univ-
catho-sjd.cm
Situation géographique Pont Joss, face la cathédrale Saint Pierre &
Paul de Douala
N° de contribuable N 000010/N/MINESUP/DDES/ESLP/SAC
Logo
1.1.2 Les objectifs de la Catho Saint-Jérôme

Depuis sa création, Saint-Jérôme s’est donné de nombreuses missions qui sont des réponses a
de nombreuses attentes tels que :
 La réponse aux challenges liés à la mondialisation et aux changements

socioéconomiques ; l’église qui entend contribuer d’une manière significative dans la
formation de l’Homme.
 La réponse à une démarche pastorale pour la libération et l’épanouissement intégral
ayant pour but de révolutionner la gestion des ressources humaines en amenant les
hommes à adopter des habitudes dans le management des biens
 La réponse aux parents à la quête de la meilleure formation pour les enfants dans un
cadre saint
 La participation à la croissance économique locale.

2
1.1.3 Structure organisationnelle

La Catho Jérôme de Douala est dirigée par un Administrateur général, sous la supervision
d'un Grand Chancelier qui n'est autre que l'archevêque métropolitain de Douala.
L'administrateur général est chargé de coordonner toutes les activités de l'Institut et de mettre
en place des stratégies qui permettront d'atteindre les objectifs fixés tout en respectant la
vision globale telle que définie par ses fondateurs. L'Administrateur général est assisté dans
ses taches par trois inspecteurs qui coordonnent les entités suivantes :
 L'inspection générale de l'Ethique.

 L'inspection générale académique.
 L'inspection générale des services
Chaque inspection est constituée de plusieurs directions qui travaillent en étroite collaboration
pour le bon fonctionnement de l'institut.
Parmi c'est directions, certaines sont consacrées à la gestion des quatre (04) différentes écoles
qui sont :
Saint Jérôme Polytechnic (SJP) est une école d'ingénieur qui vient répondre ainsi aux besoins
de formation des ressources humain à la page des avancées technologiques majeurs et capable
de proposer des solutions optimales aux problèmes de l'environnement dans lequel elles se
trouvent afin de contribuer à son développement. La formation commence par un cycle
préparatoire intégré suivi d'une orientation progressive à partir du second semestre de la
deuxième année par des enseignements plus spécialisés complétés par une formation générale
visant à maitriser l'entreprise et son environnement dans leurs différentes dimensions.
Les différentes écoles l'on retrouve au sein de cette école sont :
 Génie Infotronique (GIT)

 Génie Mécatronique (GME)
 Génie Civil (GCI)
 Génie Minier (GMI)
 Génie des Procédés (GP)
Saint Jérôme Management and Business School (SJMBS) est une école de management dont
la formation est conçue suivant la norme Licence-Master-Doctorat (LMD). Elle offre deux
possibilités de parcours à savoir la formation classique ou initiale et la formation continue ou
professionnelle. La formation y est composée de deux cycles :

2
Le cycle Licence qui a une durée de trois années soit un total de six semestres d'études.
Le cycle Master qui a une durée de deux ans, pendant lesquels l'apprenant aura la possibilité
de se spécialiser dans l'un des domaines ci-après :
 Comptabilité, Contrôle et Audit (CCA)
 Banque et Institutions Financières (BIF)
 Supply Chain Management (SCM)
 Gestion des Ressources Humaines (GRH)
 Marketing (MKT)
Saint Jérôme School of Religious and Social Science (SJRSS) est une école nouvellement
créé qui offre des formations aux étudiants dans les domaines des sciences médicales,
biomédicales et sanitaires.
Saint Jérôme School of Réligious and Social Sciences (SJRSS) est une école qui offre des
formations en philosophie et théologie. Les formations sont ouvertes à tous.
1.1.4 Situation géographique

La Catho Saint Jérôme de Douala se trouve dans la ville de Douala plus précisément dans le
quartier AKWA. Elle est située à la 5949 Rue Joss et se trouve face la cathédrale Saint-Pierre
de Douala.
1.2 Description du service dans lequel

1.2.1.1 Description du service
1.2.1.2 Les missions du service
1.3 Présentation du projet
1.3.1 Contexte et problématique
L’université Catholique Saint-Jérôme offre la possibilité à ses étudiants de développer leurs
expériences académiques par une période d’immersion en entreprise d’une durée allant de 1 à
06 mois. A la fin de ce stage, chaque étudiant est suivi par un encadreur académique et est
censé remettre un rapport de stage.
La gestion de ces rapports de stage est une activité encore dans son état embryonnaire car le
processus d’archivage des rapports de stages au sein de l’institut se fait par simple dépôt des
rapports de stage à la scolarité. Ces documents sont facilement volatiles et donc exposé à des
aléas insidieux à savoir les rongeurs, l’humidité ou tout simplement une mauvaise qualité des
encres ou du papier. C’est donc à cette optique que l’idée nous est venue de concevoir une
application mobile permettant l’archivage numérique cette application permettra de suivre
après chaque année les stages des étudiants de l’institut Catholique Saint-Jérôme de Douala

2
facilitant ainsi une consultation directe des documents depuis un terminal mobile et
améliorera la traçabilité de ces documents.
1.3.2 Objectifs du projet

Notre objectif est donc de mettre au point une plateforme facilitant la consultation numérique
des rapports de stage des étudiants de l’institut. Cette application permettra d’une part de
conserver les différents rapports des étudiants, d’autre part de faciliter leur consultation.
L’application permettra également d’intégrer des modules de recherches, de mots clés.
La bonne conduite de ce projet sera liée à des objectifs subsidiaires suivants :
 Concevoir une méthodologie ou une maquette qui permettra de présenter un aperçu de
l’application
 Développer des modules devant intégrer (la prise en charge des mots clés
l’enregistrement des rapports de stage)
Cette application permettra donc à l’administrateur de :
Rajouter des utilisateurs, d’enregistrer les données (rapports de stages, étudiants ainsi que
leurs informations
De même, cette application sera bénéfique aux étudiants dans la mesure où elle intègrera :
 Tout d’abord une fonctionnalité d’authentification : l’étudiant ainsi la possibilité
d’enregistrer ses informations via un formulaire afin de pouvoir accéder à l’interface
de l’application.
 La visualisation de l’ensemble des rapports et mémoire des étudiants de l’université en
fonction des écoles.
 L’affichage des informations relatives à un mémoire ou un rapport
 De même, une fonctionnalité permettant le téléchargement d’un mémoire.
Les critères de succès du projet seront notamment :
 L’architecture facile d’accès et d’utilisation
 Satisfaction des étudiants
1.3.3 Méthodologie
Notre méthodologie de travail a consisté en 04 principales étapes :
La première étape du travail a consisté à recueillir auprès des différents responsables le

processus d’archivage des mémoires des étudiants de l’université pour avoir une idée générale
sur l’archivage des mémoires. La question qui a guidé notre intérêt est celle de savoir
comment s’effectuait l’archivage des rapports de stage ? Qui en était en charge ? Comment

2
s’effectuait la consultation de ces rapports. Les réponses à ce questionnaire nous ont permis
d’orienter nos recherches dans la littérature.
La deuxième étape a été une revue de littérature visant à comprendre l’archivage numérique
des documents. Comment utiliser les technologies mobiles dans le processus d’archivage et à
recenser des exemples existants.
L’implémentation d’une méthodologie de conception a été la troisième étape. Elle a visé à

organiser les idées, les documenter puis organiser la réalisation. Cette étape nous a permis
d’étudier et de choisir un modèle de conception de notre application.
La dernière étape est la proposition de notre solution mobile multiplateforme ainsi qu’une
présentation des résultats obtenus.
1.3.4 Contraintes du projet

Les besoins non fonctionnels décrivent toutes les contraintes techniques, ergonomiques et
esthétiques auxquels est soumis le système pour sa réalisation et pour son bon
fonctionnement. En ce qui concerne notre application, les contraintes auxquelles elles seront
sont :
 La simplicité d’utilisation : le graphisme de l’application devra être soigné et épuré,
les menus de navigation devront être fluides.
 La fiabilité des informations : les données fournies par l’application devront être le
plus fiable possible de même l’application devra garantir la sécurité ainsi que la
confidentialité des données des utilisateurs.
 L’application devra être une solution ouverte et évoluée : on pourra procéder à des
améliorations de l’application en intégrant des modules pour garantir la souplesse,
l’évolutivité de la solution
 L’interface de l’application devra être une solution de haute performance : le temps de
réponse pour une transaction devra être minime.
 Le fonctionnement de la plateforme ne devra pas être en contradiction avec les
objectifs et les conditions d’utilisation.

2

2
Chapitre 2 REVUE DE LITTERATURE

Parallèlement au entretiens menés au sein de la Catho Saint-Jérôme, nous avons fait une étude
sur le contexte législatif et normatif concernant l’archivage numérique, ainsi qu’une analyse
des technologies informatiques impliquées dans la conservation des données électroniques.
2.1 Etat de l’art de l’archivage numérique

L’informatisation des données, la dématérialisation, les échanges électroniques sont des
questions d’actualité. Peu de domaine encore échappent à ces questionnements. Les archives
ne sont pas épargnées.
2.1.1 Définition et Objectifs
2.1.1.1 Définition
De manière générale, les archives sont définies comme des documents produits dans
l’exercice d’une activité pour garder trace des actions d’une personne ou d’une organisation
publique ou privée à travers des supports variés tels que des papiers, des photographies, les
données électroniques.
Il va sans dire que organismes publics et privés doivent faire face actuellement à une
multiplication du volume de leur archives. Se pose alors la question du stockage de ces
archives. Jusqu’à une période extrêmement récente, l’archivage ne reposait que sur la
conservation physique des supports documentaires. Or des problèmes de sécurité et
pérennisation se posent. Une solution consiste à la dématérialisation de ces documents.
Des lors, l’archivage numérique intervient comme un ensemble des actions, d’outils et
méthodes mis en œuvre pour réunir, identifier, sélectionner et classer les contenus
électroniques sur un support sécurisé dans le but de les exploiter et les rendre accessibles dans
le temps que ce soit à titre de preuve ou informatif.
2.1.1.2 Objectifs
L’archivage électronique ne se limite pas au simple stockage et partage d’information. En
plus de la conservation, elle garantit la recevabilité juridique. Le système d’archivage
électronique garanti 04 grands principes.
 Garantir la pérennité des documents
L’archivage pérenne les données qui consiste précisément à garantir l’accès, la lisibilité et
l’intelligibilité sur le long terme. La durée de conservation équivaut à celle de leur utilité sur
le plan administratif ce qui rend les données à valeur patrimoine ou à conservation
permanente.

2
 Assurer l’intégrité des documents

Les documents électroniques sont exposés à deux types de risques : l’altération intentionnelle
et l’altération non intentionnelle. Afin de prévenir ces deux risques, il est question de mettre
en place des techniques des signatures et de scellement des données.
 Assurer l’accessibilité des documents
L’archivage électronique doit permettre l’accessibilité aux archives c’est un principe que
rejoint les fonctions archivistiques, la diffusion. Un document d’archive doit pouvoir être
accessible pour pouvoir être utilisé et répondre au besoin spécifique pour lequel il a été créé.
 Garantir la confidentialité des documents
L’archivage électronique doit être sécuritaire. Le document d’archive ne doit pas être visible
que par des personnes détenant le droit d’accès. Un cryptage est utilisé pour que les données
soient lues que par les personnes autorisées.
2.1.2 La problématique
La conservation numérique doit maintenir la capacité d’afficher, d’extraire et d’utiliser les
collections numériques mais elle est dépendante de l’évolution de son environnement
informatique
2.1.2.1 La pérennité des données

Les données sont codées selon les normes de codage (ASCII étendu, ASCII standard ;
UNICOD…) les constructeurs de matériels et de logiciels informatiques n’utilisent pas les
mêmes codages, il peut donc y avoir une incompatibilit2 entre les machines (par exemple
entre un ordinateur IBM et un ordinateur Apple)
2.1.2.2 Obsolescence des technologies informatiques

Les tests pratiqués sur les différents supports par le National Media Lab contredise les
arguments des fournisseurs. Effectivement ces derniers avancent la durée de vie des supports
beaucoup plus longue que celle prouvée par les laboratoires américains. Le tableau ci-dessous
présente une étude comparative de la durée de vie de quelques supports informatiques.
Tableau 2-2 : Etude comparative de la durée de vie de quelques supports technologiques
Supports/technologies testés Durée de vie estimée par le laboratoire

La disquette Environ 8 mois
Le CD enregistrable Environ 5 ans
Le CD pressés ou CD-ROM Environ 25 ans

2
2.1.3 Fonctionnalités
Après avoir énoncé les différentes problématiques auquel se confrontent un SAE , il convient
de présenter les différentes fonctionnalités d’un système d’archivage électronique. Un SAE
sécurisé s’inscrit sur dans le cadre de cinq grandes fonctions qu’il convient de bien définir :
Tableau 2-3 : Fonctionnalités d'un SAE
Etapes Objectifs Actions Equivalent

archivages papier
Versement -Archiver le document -Archivage du document -Versement
clos décrit (métadonnées physique des
-Verser le document d’origine et/ou ajoutées) dossiers avec
dans le SAE -Transformation du bordereaux de
document pour être lisible versements
par n’importe quel outil
informatique
Stockage/ Gérer le support du -Suivi du vieillissement Gestion physique
conservation document -Gestion de l’espace des archives versées
disponible dans le local
-Scellement numérique
interdisant la modification
du document.
Gestion de Gérer les bases de -Description des Rédaction de
données données documents l’inventaire
Recherches des Utilisation des
documents ayant fait instruments de
l’objet de demande de recherches
communication
Consultation Utiliser l’interface entre Réception des demandes Communication du
le SAE et de consultation document
l’utilisateur/lecteur Communication du
document à lecteur
Planification Etablir des politiques de Veille technologique en Vérifications des
de la conservation sur le long matière de support conditions de
pérennisation terme Migrations des données conservation

2
Veille juridique
2.2 Normes concernées par l’archivage numériques
Les normes encadrent la conservation des documents. Elles permettent ainsi au organismes de
mettre en place un système de conservation sécurisé. Parmi les différentes normes qui
régulent l’archivage numérique nous avons :
2.2.1 La norme 19005(2005, révisée en 2011 et 2012)

La norme Iso 19005 1 est une norme internationale qui définit le format PDF 1.4 d’Adobe
System) comme format de fichier de document électronique placés dans un SAE devant être
conservés sur le long terme.
Ceci du fait que ce format est fidèle au document original (image, police et taille d’écriture
par exemple) ce qui permet ainsi de consulter un document sans que le logiciel que lequel il a
été créé ne soit installé sur le terminal utilisé
2.2.2 OAIS (Is 1472 : 2012) (2012, révisée en 2012)

La norme OAIS (Système ouvert d’archivage de l’information), enregistrée depuis 2003 puis
révisée en 2012 sous le nom de norme Iso 1472 : 2012 décrit le modèle pour la conception et
la mise en place d’un SAE pour que ce dernier soit pérenne peu importe les évolutions
numériques. Cette norme explique et décrit la structure de l’archivage et du fonctionnement
d’un SAE. Elle propose un schéma conceptuel d’un SAE.

2
Chapitre 3 METHODOLOGIE ET APPROCHE ADOPTEE
3.1 Etude comparative de MERISE et UML

MERISE (Méthode d’étude et de réalisation Informatique pour les systèmes d’entreprise) est
une méthode d’analyse et de réalisation de systèmes d’information qui est élaborée en
plusieurs étapes : schéma directeur, étude préalable, étude détaillée et réalisation. C’est une
méthode pour concevoir un système orienté traitement et données. Elle propose son propre
langage ainsi que les règles pour passer d’un diagramme à un autre.
L ’UML (Unified Modeling Language ) est un langage de modélisation des systèmes standard
qui utilisent les diagramme pour représenter chaque aspect d’un système c’est à dire statique,
dynamique, … en s’appuyant sur la notion d’orienté objet qui est un v2ritable atout pour ce
langage. Elle propose une boite d’outils permettant la modélisation de tout type de système
d’information
UML OU Merise ?
Les méthodologies disent qu’une méthode pour être opérationnelles doit avoir 3
composantes :
 Une démarche (étapes, phases et taches de mise en œuvre)

 Des formalismes (les modélisations et les techniques de transformation)
 Une organisation et des moyens de mise en œuvre
Merise se positionne comme une méthode de conception SI organisationnel plus tournée vers
la compréhension et la formalisation des besoins du métier que vers la réalisation de logiciel.
En ces sens que Merise se réclame plus de l’ingénierie du SI métier que du génie logiciel.
Jamais Merise ne s’est voulu une méthode de développement logiciel ni de programmation.
L’UML est par contre de par son origine (programmation objet) s’affirme comme un
ensemble de formalismes pour la conception logicielle à bas de langage objet. Il est idéal
pour :
 Concevoir et déployer une architecture logiciel développée dans un langage objet

(Java, C++) certes UML dans sa volonté unificatrice a proposé les formalismes.

2
 Pour modéliser les données (le modèle de classe réduit sans méthodes et stéréotypes
en cas d’entités) mais avec des lacunes qui ne présentait pas l’entité relation de
Merise.
 Pour modéliser le fonctionnement métier (le diagramme d’activité et de cas
d’utilisation) qui sont des formalismes très anciens qu’avait en son temps améliorée
Merise
Après cette étude comparative, il est certes que nous allons adopter UML comme langage de
modélisation puisque notre application est basée sur le concept de l’orienté Objet.
3.2 Présentation de l’UML

L’UML est une synthèse de modélisation de langages de modélisation objets antérieurs :
BOOCH, OMT, OSE. Principalement issu des travaux de GRADY Booch, James Rumbaugh
et Ivar JACOBSON, l’UML est à présent un standard adopté par l’objet management Group
(OMG). L’utilisation d’UML est un moyen utile de définir de grands systèmes complexes.
C’est un langage universel pour la modélisation qui limite les ambiguïtés et les
incompréhensions. La véritable force de l’UML est qu’il repose sur un méta modèle. En
d’autres termes la puissance et l’intérêt de l’UML est qu’il normalise la sémantique et les
concepts qu’il véhicule.
L’UML définit à ce jour 13 diagrammes. Ces diagrammes sont repartis en 02 grands

groupes :
 Les digrammes structurels

 Les diagrammes comportementaux
La figure rillustrant l’ensemble des diagrammes sera présenter en annexe
Les diagrammes utilisés dans l’ensemble de notre analyse seront présentés dans le tableau
suivant :
Tableau 3-4 : Diagrammes utilisés dans notre travail
DIAGRAMMES ROLES
Cas d’utilisation  Modéliser les besoins des utilisateurs
 Représenter les grandes fonctionnalités entre le système et
l’utilisateur
Classes  Représenter les objets du système qui vont interagir pour réaliser

2
les cas d’utilisation

3.2.1 Les avantages de l’UML
 UML est un langage formel et normalisé
 Gain de précision
 Gain de stabilité
 Encourage l’utilisation d’outils
 UML est un support de communication performant
 Il cadre l’analyse
 Il facilite la compréhension de représentations abstraites complexes
 Son caractère polyvalent et sa souplesse en font un langage universel
3.2.2 Les limites de l’UML

 La mise en place de l’UML nécessite un apprentissage et passe per période
d’adaptation.
Même si l’Esparato est une utopie la nécessité de s’accorder sur les modes d’expression
commun est vitale en informatique. UML n’est pas à l’origine des concepts objets mais en
constitue une étape majeure car il unifie les différentes approches et en donne une définition
plus formelle.
 Le processus (non couvert par l’UML) est une autre clé de la réussite d’un projet.
Or l’intégration de l’UML dans un projet et améliorer un processus est une tâche complexe et
logique.
Les auteurs de l’UML sont tout à fait conscients de l’importance du processus, mais
l’acceptabilité industrielle de la modélisation objet passe d’abord par la disponibilité
d’analyse objet et standard
3.2.3 Le 2TUP ( Two Track Unified Process)

Le 2TUP (Le 2 Track Unified Process) est un processus de développement logiciel qui
implémente le Processus Unifié.
Le 2TUP propose un cycle de développement en Y qui dissocie les aspects techniques des
aspects fonctionnels. Il commence par une étude préliminaire qui consiste essentiellement à
identifier les acteurs qui vont interagir avec le système à construire, les messages
qu’échangent les acteurs et le système, à produire le cahier de charge et à modéliser le

2
contexte ( le système est une boite noire, les acteurs l’entourent et sont reliés à lui, sur l’axe
qui lie un acteur au système on met les messages que les deux échangent dans le sens
Le processus s’articule donc autour de 03 phases essentielles :
 Tout d’abord, d’une branche technique

 Ensuite une branche fonctionnelle
 Enfin une branche de réalisation
Figure 3-1Illustration du processus 2TUP
3.3 Modélisation des différents diagrammes UML

3.3.1 Le diagramme des cas d’utilisation
C’est la première étape UML d’analyse d’un système. Il permet de recueillir, d’analyser et
d’organiser les besoins et de recenser les grandes fonctionnalités d’un système. C’est une
étape primordiale pour produire une application conforme aux attentes de l’utilisateur.
3.3.1.1 Composition du diagramme des cas d’utilisation
 Un acteur : c’est l’idéalisation d’un rôle joué par une personne externe. Un processus
ou une chose qui interagit avec un système. Il se représente par un petit bonhomme
avec un nom inscrit en dessous

2
Figure 3-2: Illustration d'un acteur
Figure 3-3
 Le cas d’utilisation : c’est une unité cohérente représentant une fonctionnalité visible
de l’extérieur. Il réalise un service de bout en bout avec un déclenchement, un
déroulement et une fin, pour l’acteur qui l’initie.
Un cas d’utilisation modélise donc un service rendu par le système sans imposer le
mode de réalisation de ce service. Il représente par une ellipse contenant le nom du cas
(un verbe à l’infinitif) et optionnellement au-dessus du nom un stéréotype. La figure
ci-dessous illustre le modèle d’un cas d’utilisation
Figure 3-4 Illustration d'un cas d'utilisation
 Les relations : trois types de relations sont pris en charge par la norme UML et sont
graphiquement représentés par des types particuliers de ces relations. Les relations
indiquent que le cas d’utilisation source présente les mêmes conditions d’exécution
que le cas issu. Une relation simple entre un acteur et une utilisation est un trait
simple.
3.3.1.2 Identification des acteurs

Le tableau ci-dessous regroupent l’ensemble des acteurs de notre système.
Acteur Rôle
Visiteur C’est un individu qui télécharge
l’application cherchant des mémoires et des
rapports de stage.
Etudiant C’est un étudiant ayant un compte sur notre
application. Il peut donc consulter les
mémoires et les rapports ainsi que les

2
télécharger
L’administrateur C’est l’individu qui assure le dynamisme de
l’application ; les mises à jour de
l’application, de leur disponibilité ainsi la
gestion des comptes des étudiants.
Figure 3-5: Tableau des acteurs de notre système
3.3.1.3 Diagrammes des cas d’utilisation de notre application

3.3.1.3.1 Le diagramme de cas d’un visiteur
Lorsqu’un individu télécharge l’application il ne possède que la possibilité de consulter le
catalogue des mémoires classés en fonction des écoles ainsi que la possibilité de se connecter
pour accéder à plus de fonctionnalités.
Figure 3- 6: Illustration du diagramme des cas d'utilisation d'un visiteur
3.3.1.3.2 Le diagramme des cas d’utilisation d’un étudiant

Après la connexion de l’étudiant, ce dernier a la possibilité de suivre le processus de
téléchargement

2
Figure 3-7: Illustration du cas d'utilisation d'un étudiant
3.3.1.3.3 Le diagramme des cas d’utilisation de l’administrateur

L’administrateur après connexion à la possibilité de gérer les comptes, les rapports. Il gère
donc toute la mise en place technique
Figure 3-8: Illustration du cas d'utilisation de l'administrateur
3.3.1.3.4 Diagramme des cas d’utilisation globale

L’analyse des fonctionnalités prévues dans le cahier de charges nous permet de dégager ou
encore d’identifier les cas d’utilisation de notre application.
Le tableau ci-dessous résume les cas d’utilisation identifiée.

2
Tableau 3- 5: Tableau de l'ensemble des cas d'utilisation de notre système
N° Cas d’utilisation
1. Se connecter
2. Ajouter des comptes
3. Ajouter des documents
4. Ajouter des étudiants
5. Modifier les informations des documents
6. Modifier les informations des étudiants
7. Supprimer les informations des étudiants
8. Supprimer les informations des documents
9. Consulter les documents en fonction des écoles
10. Consulter les rapports et mémoires en fonction de leur catégorie
11. Afficher les informations d’un mémoire ou d’un rapport
12. Effectuer une recherche
13. Télécharger un mémoire ou rapport
Description du cas d’utilisation « Authentifier »
Dans le tableau suivant nous allons détailler le cas d’utilisation « s’authentifier » qui

s’accompagne du scenario nominal

2
Tableau 3- 6: Description détaillée du cas d'utilisation "S'authentifier"
SOMMMAIRE
Titre Identification
But Saisir une adresse email et un mot de passe afin de pouvoir se connecter
Résumé Apres avoir entré son adresse email et son mot de passe, l’utilisateur peut
accéder à une interface si il ses données sont valides et peut ainsi accéder
à toutes les fonctionnalités de l’application.
Acteur Administrateur et l’étudiant
DESCRIPTIONS DES ENCHAINEMENTS
Préconditions Post –conditions
- Il accède à l’interface de connexion - Saisir son adresse mail ainsi que son
de connexion login
Scenario nominal
1. L’utilisateur est authentifié
2. Si les données sont correctes le contenu de la plateforme s’affiche
3. L’ensemble des taches s’affiche et il peut ainsi consulter ses taches par simple clic.
Enchainement alternatif
L’utilisateur n’a pas rempli tous les champs ou les données sont incorrectes
Le système affiche un message d’erreur
Retour à l’étape 1 du scenario nominal pour lancer à défaut la connexion
A défaut le client clique sur mot de passe oublié il est invite à saisir son adresse email
Un message est envoyé vers sa boite email avec son nouveau mot de passe
Description du cas d’utilisation « Gestion des comptes étudiants »
Dans le tableau suivant nous allons détailler le cas d’utilisation « Gestion des comptes
étudiants » qui s’accompagne du scenario nominal
Tableau 3- 7: Description détaillée du cas d'utilisation « Ajout des comptes »
SOMMMAIRE
Titre Ajouter des comptes étudiants
But Permettre à l’administrateur d’ajouter des comptes des étudiants
Résumé Apres avoir entré son adresse email et son mot de passe, l’administrateur
peut accéder à une interface si il ses données sont valides et peut ainsi
accéder à la fonctionnalités lui permettant de gérer les comptes des

2
étudiants.
Acteur Administrateur de l’application mobile
- L’administrateur est authentifie - Il clique sur l’option « Ajout des
comptes »
Scenario nominal
1. L’administrateur est authentifié
4. Il clique sur l’option d’ajout des comptes étudiant
5. Le système affiche une interface présentant un formulaire et il peut ainsi ajouter les
comptes en remplissant formulaire
Description du cas d’utilisation « Ajouter des documents »
Dans le tableau suivant nous allons détailler le cas d’utilisation « Gestion des mémoires et des
rapports de stage » qui s’accompagne du scenario nominal
Tableau 3- 8: Description détaillée du cas d'utilisation « Ajouter des documents »
SOMMMAIRE
Titre Ajouter des documents
But Pouvoir ajouter les mémoires et rapports des étudiants.
Résumé Après avoir entré son adresse email et son mot de passe,
l’administrateur peut accéder à une interface si ses données sont valides
et peut ainsi accéder à la fonctionnalité lui permettant de gérer des
documents et rapports.
Acteur Utilisateur de l’application mobile

2

- L’administrateur est authentifié - Il remplit le formulaire d’ajout et les
données sont vérifiés puis
enregistrées dans le système.
Scenario nominal
3. L’ensemble des taches s’affiche et il peut ainsi consulter ses taches par simple
clic.
4. Il choisit l’option d’ajout des documents
5. Le système le renvoi vers une interface présentant un formulaire ou il peut
aisément rempli.
6. Apres vérification les données sont ajoutés dans le système
Description du cas d’utilisation « Modifier des documents »
Dans le tableau suivant nous allons détailler le cas d’utilisation « Modifier des mémoires et
des rapports de stage » qui s’accompagne du scenario nominal
Tableau 3-9: Description détaillée du cas d'utilisation «Modification des documents »
SOMMMAIRE
Titre Modifier des documents
But Pouvoir modifier les mémoires et rapports des étudiants.
Résumé Après s’être authentifié l’administrateur peut accéder à une interface si
ses données sont valides et peut ainsi accéder à la fonctionnalité lui
permettant de modifier des documents et rapports.
Acteur L’administrateur de l’application mobile

2
- L’administrateur est authentifié - Il clique remplit le formulaire

d’ajout et les données sont vérifiés
puis enregistrées dans le système.
Scenario nominal
4. Il choisit l’option d’ajout des documents
5. Le système le renvoi vers une interface présentant un formulaire ou il peut
aisément rempli.
6. Apres vérification les données sont ajoutés dans le système
Description du cas d’utilisation « Supprimer les documents »
Dans le tableau suivant nous allons détailler le cas d’utilisation « Supprimer les documents »
qui s’accompagne du scenario nominal
Tableau 3-10: Description détaillée du cas d’utilisation « Supprimer des documents »
SOMMMAIRE
Titre Supprimer les documents
But Permettre à l’administrateur de pouvoir supprimer les mémoires et
rapports.
Résumé Apres s’être authentifié , l’administrateur accède à la tache de gestion des
comptes au cours duquel il peut modifier supprimer des rapports et
mémoires
Acteur Administrateur
- L’administrateur est authentifié - Il choisit l’option de gestion des

2
documents
Scenario nominal
3. L’ensemble des taches s’affiche et il peut ainsi consulter la tache de gestion des
documents par simple clic.
4. Il clique sur la tache de gestion des documents et accède a la liste des documents
il peut ainsi sélectionner un document et le supprimer
Description du cas d’utilisation « consulter la liste des mémoires »
Dans le tableau suivant nous allons détailler le cas d’utilisation « consulter la liste des
mémoires » qui s’accompagne du scenario nominal
Tableau 3- 11: Description du cas d'utilisation « consulter des mémoires en fonction des
écoles »
SOMMMAIRE
Titre Consulter la liste des mémoires en fonction des écoles
But Lister les mémoires stockés dans le système
Résumé Apres le téléchargement de l’application l’utilisateur est dirigé vers une
page ou est répertorié l’ensemble des mémoires et rapport classifiés par
école
Acteur Visiteur
- L’utilisateur télécharge l’application - Afficher l’interface présentant la
- L’utilisateur clique sur le bouton classifications des mémoires
«Mémoire en ligne»
Scenario nominal

2
1. L’utilisateur télécharge l’application

2. Il accède à l’interface de bienvenue du système
3. Il clique sur le bouton « Mémoire en ligne »
4. Le système expose l’interface de classification des rapports et mémoires
5. Lorsque le visiteur clique sur une catégorie souhaitée
6. Le système le renvoie vers l’interface correspondant
7. Lorsque le visiteur clique sur un mémoire il reçoit un message lui demandant de se
connecter et est alors renvoyé vers la page de connexion.
Description du cas d’utilisation « Effectuer une recherche »
Dans le tableau suivant nous allons détailler le cas d’utilisation « effectuer une recherche »
qui s’accompagne du scenario nominal
Tableau 3- 12: Description détailllée du cas d'utilisation « Effectuer une recherche»
SOMMMAIRE
Titre Effectuer une recherche
But Lister les mémoires stockés dans le système par filière
Résumé L’utilisateur accède à la liste des mémoires, il clique sur le menu de
recherche, l’action se déclenche et il peut ainsi saisir le titre du mémoire
recherché. Apres validation le résultat de sa recherche s’affiche.
Acteur Utilisateur de l’application mobile
- L’utilisateur télécharge l’application - Il sélectionne le menu de recherche
et saisi le titre du mémoire
recherché
Scenario nominal
1. Le client télécharge l’application
2. Il clique sur le bouton « Mémoire en ligne »
3. Il est renvoyé vers une page où se trouve l’ensemble des sujets traités
4. Il clique sur le menu de recherche
5. Il saisit le titre du mémoire recherché

2
Description du cas d’utilisation « Afficher les informations de chaque mémoire »
Dans le tableau suivant nous allons détailler le cas d’utilisation « Afficher les informations
des mémoires » qui s’accompagne du scenario nominal.
Tableau 3-13: Description détaillée du cas d'utilisation « Afficher les informations d'un
mémoire »
SOMMMAIRE
Titre Afficher les informations relatives à chaque mémoire
But De permettre à l’étudiant d’obtenir d’amples informations concernant un
mémoire ou un rapport
Résumé L’interface de liste des mémoires et rapports étant chargé, l’étudiant a la
possibilité de cliquer sur l’icône de vue et peut ainsi accéder à une
interface ou sera affiché les informations concernant ce mémoire.
Acteur Etudiant
- L’étudiant est authentifié - Les informations concernant le
thème est affiché
Scenario nominal
1. Il accède à l’espace étudiant
2. Il fait le choix de la catégorie d rapports qu’il souhaite consulter
3. Le système expose la liste des titres des mémoires suivis du nom de l’étudiant et de
l’aperçu du résumé du mémoire.
4. L’utilisateur clique sur un titre
5. Le système affiche les informations du mémoire en question
Description du cas d’utilisation « Télécharger les fichiers numériques des mémoires »
Dans le tableau suivant nous allons détailler le cas d’utilisation « Télécharger les mémoires et
rapports » qui s’accompagne du scenario nominal.

2
Tableau 3-14: Description détaillée du cas d’utilisation « Télécharger les supports

numériques des mémoires»
SOMMMAIRE
Titre Télécharger les fichiers numériques des mémoires
But Cliquer sur le bouton de téléchargement
Résumé Lorsque l’étudiant est authentifié il a possibilité d’accéder à la
fonctionnalité de téléchargement des mémoires
Acteur Etudiant
- L’étudiant est authentifié - Il clique sur l’icône de
téléchargement
Scenario nominal
1. Le client se connecte à l’application par le login et un mot de passe.
2. Le système le renvoi l’espace étudiant
3. Le client clique sur la rubrique documents qu’il souhaite consulter
4. Il clique sur le titre d’un document et le système affiche une interface contenant les
informations du document choisi
5. Il clique sur l’icône de téléchargement
3.3.2 Diagramme de classe

C’est un schéma utilisé en génie logiciel pour présenter les classes et les interfaces des
systèmes ainsi que leur relation. Ce diagramme permet de décrire clairement la structure d’un
système c'est-à-dire une description complète de la structure des objets et d’informations
utilisées dans notre application mobile, à la fois en interne et en communication avec ses
utilisateurs. Il décrit les informations sans faire référence à une implémentation particulière.
Ses classes et relations peuvent être implémentés de nombreuses manières comme les table de
bases de données, les nœuds XML ou encore les compositions d’objets logiciels.
3.3.2.1 Composition d’un diagramme de classe

En général, un diagramme de classe peut contenir les éléments suivants :

2
 Les classes : une classe représente la description formelle d’un ensemble d’objets
ayant une sémantique et des caractéristiques communes. Elle est représentée en
utilisant un rectangle divisé en trois sections :
La section supérieure est le nom de la classe, la section centrale définit les propriétés
de la classe alors que la section du bas énumère les méthodes de la classe.
 Les associations : une association est une relation entre deux classes (association
binaire) ou plus (association n-aire) qui décrit les connexions structurelles entre
plusieurs instances. Une association indique donc que les liens peuvent exister entre
des instances des classes associées.
 Les attributs : les attributs représentent les données encapsulées dans les objets des
classes. Chacune de ces informations est définie par un nom, un type de données, une
visibilité et peut être initialisé. Le nom de l’attribut doit être unique a une classe
La figure représentant le diagramme de classe sera présentée en annexe.
3.4 L’architecture MVC

3.4.1 Présentation
Le modèle MVC est une façon d’organiser une interface graphique d’un programme. Elle
consiste à distinguer trois entités distinctes qui sont le modèle, la vue et le contrôleur
L’organisation globale d’une interface graphique est souvent délicate. Bien que la façon MVC
d’organiser une interface graphique ne soit pas la solution miracle. Elle fournit une première
approche qui peut ensuite être adaptée. Elle offre aussi un cadre pour structurer l’application
3.4.2 Composition de l’architecture MVC

Dans l’architecture MVC le rôle des trois entités sont les suivants
3.4.2.1 Le modèle
Il contient les données manipulées par le programme. Il assure la gestion de ces données et
garantit leur intégrité. Dans le cas pratique d’une base de données c’est le modèle qui la
contient. Le modèle offre les méthodes pour mettre à jour ces données (insertion, suppression
changement de de valeur) il offre aussi les méthodes pour récupérer ces données, le résultat
renvoyé par le modèle sont dénués de toute présentation.
3.4.2.2 La vue
La vue correspond à l’interface avec lequel l’utilisateur interagit. Sa première tâche est de
présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes les

2
actions de l’utilisateur (clic de souris, sélection d’une entrée boutons) ces différents
évènements sont envoyés au contrôleur. La vue n’effectue aucun traitement. Elle se contente
d’afficher les résultats de traitements effectuées par le modèle et interagit avec l’utilisateur.
3.4.2.3 Le contrôleur
Le contrôleur prend en charge la gestion des évènements de synchronisation pour mettre à
jour la vue ou le modèle et les synchroniser. Il reçoit tous les évènements de l’utilisateur et
enclenche les actions à effectuer. Si une action nécessite un changement des données le
contrôleur demande la modification des données au modèle. Ce dernier avertit la vue que les
données ont changés pour qu’elle se mette à jour. Certains évènements de l’utilisateur
concernent nt pas les données mais la vue. Dans ce cas le contrôleur demande à la vue de se
modifier le contrôleur n’effectue aucun traitement, ne modifie aucune donnée. Il analyse la
requête du client et se contente d’appeler le modèle adéquat et de renvoyer la vue
correspondant à la demande.
La figure suivante présente l’architecture du modele MVC.
Figure 3- 9: Illustration de l’architecture MVC
3.4.3 Avantages du modèle MVC

Ce modèle présente de nombreux avantages telles que :
 Une meilleure organisation du code

 La diminution de la complexité lors de la conception
 La conception claire et efficace grâce à la séparation des données de la vue et du
contrôleur
 La possibilité de réutilisation du code pour d’autre applications
 Un gain de temps et de maintenance
 Une plus grande facilité pour les tests unitaires.

2
Chapitre 4 : Résultats et discussion

Après avoir élaboré une conception détaillée des cas d’utilisation ainsi que le diagramme de
classe complet dans le chapitre précédent nous devons aborder la partie implémentation dans
ce qui suit en justifiant nos choix technologiques ainsi que l’exposition des résultats obtenus.
Nous allons donc présenter dans un premier temps la conception graphique de notre
application ainsi que l’environnement matériel et logiciel de développement.
4.1 Conception graphique

4.1.1 Synopsis
Le synopsis est l’une des étapes les plus intéressantes dans la scénarisation puisqu’il contient
une description du projet qui nous aide à avoir une idée sur le produit.
4.1.1.1 Présentation du produit

Le tableau suivant présente une beve description du produit réalisé
Tableau 4-15 Description du projet
Objectifs Concevoir et réaliser une application

mobile pour la gestion des archives des
mémoires et rapports de stages des
étudiants de la Catho Saint-Jérôme de
Douala
Type d’application C’est une application informative
Support Application mobile multiplateforme
Public cible Cette application s’adressera aux utilisateurs
de Smartphones « ANDROID» et
« APPLE »
Contexte d’utilisation L’application est fonctionnelle sur
ANDROID et Apple
Langage utilisée Français
Description Ce projet consistera à concevoir et réaliser
une application mobile multiplateforme très
simple à l’usage qui permettra de gérer
l’ensemble des archives des rapports et
mémoires des étudiants de l’institut

2
Catholique Saint Jérôme de Douala.
4.1.1.2 La charte graphique

La charte graphique est l’ensemble des codes graphiques ; colorés et formels crée pour la
communication visuelle d’une entreprise. C’est la mission du concepteur d’élaborer un certain
nombre de règle donnant une unité et une cohérence aux activités du système
4.1.1.2.1 Le logo
4.1.1.2.2 Les couleurs
Figure 4-10: les couleurs de l'application
 Le bleu : c’est une couleur que l’on habitude de voir notamment dans la nature (le ciel
et la mer). Et d’ailleurs couleur de l’océan ; le bleu évoque ainsi les idées de voyage,
de découvertes, d’horizons lointains. Dans cette perspective ; le bleu dans notre
contexte évoque la connaissance c'est-à-dire la compréhension, aux question
fondamentales ; à la profondeur des choses
 Le jaune : c’est une couleur associée à la joie, la bonne humeur il est synonyme de
soleil par extension la vie, la puissance, l’énergie.
 Le blanc : il suggère la pureté, la propreté et la perfection. Considérée comme une
couleur froide il apporte de la brillance et de la clarté.
 Le rouge : c’est une couleur fascinante qui aime jouer sur les paradoxes. Elle
représente à la fois l’amour et la colère ; la sexualité et le danger. C’est une couleur
très vive qui évoque dans ce contexte le labeur, la souffrance

2
4.2 Outils
4.2.1 Choix technique
4.2.1.1 Choix de développement
4.2.1.1.1 Ionic
Figure 4- 11: Logo d'Ionic
Le Framework Ionic est un mélange d’outils pour développer des applications hybrides
rapidement et facilement. En effet, ce Framework est une surcouche du Framework
AngularJs, Angular2 ou Angular4 (dépendant de la version d’Ionic). IONIC dispose de
plusieurs avantages car il permet de produire des applications hybrides. C’est à dire on aura
besoin d’un seul code source pour créer des versions sous Android, iOS, Windows Phone ou
encore BlackBerry. Tout ceci se fait avec l’appui d’Apache Cordova qui génèrera un
exécutable avec l’extension « APK » pour la plateforme ANDROID.
De plus c’est un Framework Open source basé sur le langage HTML 5, SCSS et JavaScript.
L’objectif de ce Framework est d’offrir un développement court, efficace et ne nécessitant pas
de grandes connaissances dans le domaine. Le développement Web étant souvent la première
chose que tout informaticien apprend, il est donc très facile e sa lancer dans la création d’une
application utilisant le Framework Ionic.
La figure sivante présente l’architecture d’une application ionic.
Figure 4-12: Architecture d'une application Ionic

2
4.2.1.1.2 Apache Cordova
Figure 4-13: Logo de d'Apache Cordova
Apache Cordova est un Framework de développement mobile open source qui permet
d’exploiter les technologies telles que le HTML 5, le CSS 3 et le Javascript pour développer
des applications multiplateformes. Les applications s’exécutent dans les wrap pers ciblés pour
chaque plateforme, elle s’appuient sur des API conformes aux standards permettant l’accès
aux capteurs de chaque appareils ainsi qu’à l’état du réseau.
L’essentiel de la technologie cordova est une API JavaScript. Elle joue le rôle de « Wrapper »
(enveloppeur) pour le code natif afin de rendre cohérente l’application avec les dispositifs
mobiles. On peut considérer cordova comme un conteneur d’application qui s’intègre avec le
WebView pour l’affichage de la page Web quel que soit son contenu (JQuery, Angular JS).
Suivant le système d’exploitation Cordova s’adresse par exemple à la classe native Objective
C UNWebView sur Ios ou à la classe Android android.webkit.WebView
4.2.1.1.3 Angular
Figure 4- 14: Logo d'Angular JS
Ionic embarque le célèbre Framework Angular2. C’est un Framework JavaScript permettant

de développer des applications web. C’est un Framework qui se veut extensible et pousse vers
un développement web structuré en couches, le but étant n’étant pas d’ajouter de simples
animations au DOM mais d’apporter un aspect applicatif au front office.

2
4.2.1.2 Environnement logiciel

4.2.1.2.1 Le HTML 5
Figure 4-15: logo du HTML 5
Le Framework Ionic embarque la dernière version du HTML. La version html 5 a été finalisée
en octobre 2014. Le html est un langage balisé permettant de structuré les données d’une page
internet.
4.2.1.2.2 LE SCSS
Le Framework Ionic embarque également aussi le SCSS. Ce format de fichier a la même
particularité que les fichiers CSS pour formater le texte. Cependant il dispose de
fonctionnalités syntaxiques en plus comme les variables par exemple. Il est à noter qu’un
fichier CSS est un fichier SCSS valide car le SCSS n’est qu’une extension de ce format.
4.2.1.2.3 Visual Studio code
Figure 4-16: Logo du Visual Studio Code
Visual Studio Code est un éditeur de code extensible développé par Microsoft pour Windows,
Linux et MacOs. Les fonctionnalités incluent la prise en charge, du débogage, la mise en
évidence de la syntaxe, la complétion auto intelligente du code.
4.2.1.2.4 NODEJS
Figure 4-17: Logo de Node js

2
NodeJs est une plateforme logicielle permettant d’exécuter du code JavaScript coté serveur. Il
se démarque par l’utilisation d’un système de boucle qui permet l’exécution d’opérations de
manière asynchrone. On en effet besoin de NodeJs pour texter les scripts Anguler 2 en mode
développement.
4.2.1.2.5 Emulateur, Smartphone, navigateur
Figure 4-18: Logo de Google
Pour tester le rendu de l’application, nous avons utilisé dans un premier temps le navigateur
avec le serveur de NodeJs ensuite, pour rendre le travail moins laborieux nous nous sommes
tournés vers un smartphone Android ou nous pouvions effectuer de manipulation sur le
téléphone avec la souris.
4.2.1.2.6 SQLite
Figure 4-19: Logo de SQLite
SQLite est un système de base de données ou une bibliothèque proposant un moteur de base
de données relationnelle. Il repose sur une écriture en C ; un langage de programmation
impératif, et sur une accessibilité via le langage SQL( Structured Query Language)
SQLite présente la particularité d’être directement intégré aux programmes et dans

l’application utilisant la bibliothèque logicielle alors que ses concurrents comme MYSQL
reproduisent de leur côté le schéma classique client-serveur. Avec SQLite, la base de données
est intégralement stockée dans un fichier indépendant du logiciel.

2
4.2.1.2.7 Firebase
Figure 4- 20: Logo de Firebase
Firebase est le nom d’une plateforme mobile Google qui facilite la création de back end à la
fois scalable et performant. En d’autres termes il s’agit d’une plateforme qui permet de
développer rapidement des applications pour mobile et pour le web.
Elle propose un ensemble de services d’hébergement pour n’importe quel type d’application.
Nous avons fait usage des services d’hébergement afin de stocker les fichiers numériques des
rapports et mémoires
4.2.1.2.8 DB BROWSER for SQL ite
Figure 4-21: Logo de DB BROWSER for SQLite
Ce logiciel nous a été très utile en ce qui concerne les requêtes SQL puisqu’il nous permettait
de tester les requêtes avant même de les mettre dans le code de l’application. En effet SQLite
est comme son nom l’indique « léger ».
4.2.1.2.9 EdrawMax
Figure 4-22: Logo d'EdrawMax
EdrawMax est un logiciel de diagrammes tout en un conçu pour simplifier la création

d’organigramme, de diagrammes d’UML et de diagramme électrique.

2
Ce dernier nous a aidé à réaliser l’intégralité de nos diagrammes UML.
4.3 Les fonctionnalités développées

Dans ce qui suit nous allons présenter quelques interfaces de l’application en citant les détails
de chaque imprime écran
4.3.1 Présentation de l’interface de l’application

4.3.2 Présentation de l’interface d’authentification
4.3.3 Présentation de l’interface de l’espace utilisateur
4.3.4 Interface de l’espace étudiant
4.3.5 Présentation de l’interface de gestion des comptes
4.3.6 interfac
4.3.7 Présentation de l’interface de consultation des mémoires

2
Conclusion Générale
Le présent rapport a été rédigé dans le cadre de la réalisation de notre projet au sein de la
Catho Saint-Jérôme de Douala durant une période de 02 mois. Aujourd’hui, l’informatique
mobile atteint une prodigieuse évolution technologique. Cette évolution est nécessaire pour
remédier aux problèmes rencontrées dans la vie courante. Dans ce contexte il a donc été pour
nous de trouver et d’implémenter une application mobile conçu pour effectuer la mise en
ligne des mémoires et des rapports de stage des étudiants. Nous sommes arrivés à développer
une application mobile multiplateforme dont l’objectif majeur est d’effectuer l’archivage des
documents.
La réalisation de ce travail est organisée en 03 grandes phases, tout d’abord nous avons
commencé par une étude préalable de notre de notre projet visant à assimiler le système déjà
existant permettant ainsi de définir les principaux intervenants et d’identifier les besoins. La
deuxième phase de notre travail concerne la conception d’une architecture de base stable qui
est le point de départ à la conception dans laquelle nous avons utilisé UML comme langage de
modélisation. Enfin nous avons réalisé un outil simple et efficace qui permet à l’utilisateur de
consulter les mémoires et rapports des étudiants en ligne.
L’outil réalisé est satisfaisant cependant de nouvelles perspectives reste envisageable comme
la conception d’un site web permettant une gestion globale par l’administrateur ; permettre à
l’utilisateur de stocker ses documents. Ce travail est une œuvre humaine, n’est pas un modèle
parfait. C’est donc pourquoi nous restons ouverts à toutes les critiques et sommes prêts à
recevoir toutes les suggestions et remarques tendant à améliorer d’avantage cette étude.

2
REFERENCES BIBLIOGRAPHIQUES
WEBTOGRAPHIE
[1] https://www.freakyjolly.com/ionic-alert-this-alertcontroller-create/ consulté le 2 Avril
2020 à 16h
[2] https://www.memoireonline.com/11/13/7773/Conception-et-developpement-d-une-
application-mobile-de-vente-flash-sous-android.html.Consulté le 22 Avril 2021 à 14h
[3] https://medium.com/ampersand-academy/ionic-4-modal-example-da9694fa0f53.
Consulté le 29 Avril 2021 à 09 h.
[4] https://github.com/bharathirajatut/ionic4-higher-example/tree/master/cart-crud-php-
mysql-example/cart-ui. Consulté le 29 Avril 2021 à 17h
[5] https://forum.ionicframework.com/t/how-to-use-the-ion-searchbar-with-databases/
79863/2 Consulté le 30 Avril 2021 à 12h
[6] https://www.remotestack.io/ionic-sqlite-database-crud-offline-mobile-app-tutorial/.
Consulté le 29 Avril 2021 à 21 h
[7] https://www-positronx-io.cdn.ampproject.org/v/s/www.positronx.io/how-to-build-list-
filtering-and-searching-in-ionic/amp/?
amp_js_v=a6&amp_gsa=1&usqp=mq331AQHKAFQArABIA%3D
%3D#aoh=16229897815497&referrer=https%3A%2F%2Fwww.google.com&amp_tf=Source
%C2%A0%3A%20%251%24s. Consulté le 30 Avril 2021 à 05h .
[8 https://www.joshmorony.com/high-performance-list-filtering-in-ionic-2/.Consulté le
30 Avril 2021 à 12 h.
[9] https://rosedienglab.defarsci.org/a-quoi-sert-une-architecture-mvc-son-
fonctionnement/.Consulté le 01 Mai 2021 à 9h
[10] https://lipn.univ-paris13.fr/~gerard/uml-s2/uml-cours01.html Consulté le 02 mai 2021

à 12h
[11] https://fr.m.wikipedia.org/wiki/Diagramme_de_classes.Consulté le 03 Mai 202 a 17h
[12] https://laurent-audibert.developpez.com/Cours-UML/?page=diagramme-classes
consulté le 3 Mai 2021 a 23h
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page XI

2
[13] https://openclassrooms.com/fr/courses/4670706-adoptez-une-architecture-mvc-en-
php/4678736-comment-fonctionne-une-architecture-mvc Consulte le 03 mai 2021
Avril à 5h
[14] https://fr.slideshare.net/RimEnnour/projet-fin-dtude-application-mobile. Consulté le

15 Mai 2021 à 7h
[15] file:///storage/emulated/0/Download/projet-fin-dtude-application-mobile-33-638.jpg
Consulté le 20 Mai 2021 à 7h
[16] https://www.freakyjolly.com/ionic-sqlite-tutorial-using-crud-operations/ Consulté le

30 Mai 2021 à 8h
[17] https://www.remotestack.io/ionic-angular-firebase-authentication-example-tutorial/
Consulté le 30 Mai 2021 à 17h
[18] https://www.freakyjolly.com/ionic-sqlite-tutorial-using-crud-operations/ . Consulté le

31 Mai 2021 à 17h
[19] https://drissas.com/cours-ionic-facile/. Consulté le 31 Mai 2021à 19h.
[20] https://fr.yeeply.com/blog/langages-programmation-type-developpement/ consulter le

01 Juin 2021 à 17h
[21] https://stackoverflow.com/questions/46767431/how-to-implement-searching-and-
filtering-in-ionic Consulté le 02 Juin 2021 à 17h .
[22] https://openclassrooms.com/forum/sujet/merise-ou-uml-aide Consulté le 03 Juin 2021

à 17h
[23] https://manurenaux.wp.imt.fr/2013/09/25/uml-pour-modeliser-les-donnees-2/.
Consulté le 04 Juin 2021 à 10h.
[24] https://laurent-audibert.developpez.com/Cours-UML/?page=diagramme-classes
Consulté le 05 Juin 2021 à 5h.
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page XII

2
ANNEXES DIAGRAMMES DES CAS D’’UTILISATION
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page XIII

2
ANNEXE : DIAGRAMME DE CLASSE
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page XIV

2
ANNEXES
CYCLE DE DEVELOPPEMENT D’UNE APPLICATION APACHE CORDOVA
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page XV

2
ANNEXE SCHEMA DE L’ENSEMBLE DES DIAGRAMMES UML
RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page XVI

Final Rapport

Transféré par

Droits d'auteur :

Formats disponibles

Final Rapport

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Final Rapport

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON

MINISTERE DE L’ENSEIGNEMENT MINISTRY OF HIGHER EDUCATION

INSTITUT UNIVERSITAIRE SAINT JEROME CATHOLIC

SAINT- JÉRÔME POLYTECHNIQUE

CONCEPTION ET REALISATION D’UNE APPLICATION MOBILE

Par MOMO KEUDEM AUDREY NATACHA

Stage Numéro : 20-SJP2-LT-012-01

Effectué au sein de l’entreprise :

Mme Sombsi Adèle Mme Sombsi Adèle

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE II

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE III

TABLE DES FIGURES

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE IV

LISTE DES TABLEAUX

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE V

LISTE DES ABBREVIATIONS

APK : Android Package

ASCII : American Standard for Information Interchange

CSS : Cascading Style Sheets

DOM : Document Objet Model

HTML : Hypertext Markup Language

Ios : Iphone Operating Système

SAE : Système d’Archivage Electronique

UML : Unified Modeling Language

2TUP :2Track Unified Language

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE VI

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE VII

3.1 Etude comparative de MERISE et UML....................................................................12

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE VIII

Mots clés : Application mobile, Archivage électronique, XML, Ionic

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE IX

Key Words: Mobile applicatuion, electronic archives, Ionic.

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA PAGE X

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page 1

Chapitre 1 : Aperçu général et cadre du projet

1.1.1 Historique et évolution

 Le 23 Septembre 2009, la Catho Saint-Jérôme de Douala obtient pour l’autorisation

Le tableau suivant présente la fiche signalétique de l’entreprise.

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page 2

Tableau 1-1: Fiche signalétique de l'entreprise

Dénomination Sociale Université Catholique Saint-Jérôme de

1.1.2 Les objectifs de la Catho Saint-Jérôme

 La réponse aux challenges liés à la mondialisation et aux changements

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page 3

1.1.3 Structure organisationnelle

 L'inspection générale de l'Ethique.

Les différentes écoles l'on retrouve au sein de cette école sont :

 Génie Infotronique (GIT)

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page 4

1.1.4 Situation géographique

1.2 Description du service dans lequel

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page 5

1.3.2 Objectifs du projet

La première étape du travail a consisté à recueillir auprès des différents responsables le

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page 6

L’implémentation d’une méthodologie de conception a été la troisième étape. Elle a visé à

1.3.4 Contraintes du projet

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page 7

RAPPORT REDIGE PAR MOMO KEUDEM AUDREY NATACHA Page 8

Chapitre 2 REVUE DE LITTERATURE