Rapport de Stage

REPUBIQUE DU CAMEROUN REPUBLIC OF CAMEROON
********* **********
Paix-Travail-Patrie Peace-work-fatherland
********** ********
MINISTERE DE L’ENSEIGNEMENT MINISTRY OF HIGHER
SUPERIEUR EDUCATION
************* *************
UNIVERSITE DE DSCHANG UNIVERSITY OF DSCHANG
********** **********
INSTITUT UNIVERSITAIRE ET ESTUARY ACADEMIC AND
STRAEGIQUE DE L’ESTUAIRE STRATEGIC INSTITUTE
********* *********
RAPPORT
DE STAGE
THEME : DEVELOPPEMENT ET INTEGRATION
D'UN MICROSERVICE DE GESTION DE
DOCUMENTS NUMERIQUES DANS UNE
PLATEFORME ACADEMIQUE
LICENCE PROFESSIONNELLE
FILIERE : GENIE INFORMATIQUE ET RESEAU
SPECIALITE : GENIE LOGICIEL (GL)
Rédigé et présenté par :

NJIKAM MOUNPOU Mohamed Salim
Sous l’encadrement :
Académique de : Professionnel de :
M. TEJIOGNI Marc M. LIONEL MUNKABU
Manager des Systèmes d’Information Chef des opérations bancaire
et Infrastructures (MS2I) Afriland First Bank
ANNEE ACADEMIQUE : 2022-2023

DEVELOPPEMENT ET INTEGRATION D'UN MICROSERVICE DE GESTION DE
DOCUMENTS NUMERIQUES DANS UNE PLATEFORME ACADEMIQUE
EPIGRAPHIE
‘La technologie ne remplace pas les

enseignants, mais les enseignants qui utilisent
la technologie remplacent ceux qui ne
l'utilisent pas ‘
Sidney Hook
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim II

DEDICACE
A ma
très
chère
famille.
REMERCIEMENTS
Plus qu’une partie formelle de notre travail, c’est un devoir moral de témoigner notre
gratitude à tous ceux qui ont contribué à l’élaboration de ce rapport portant sur le
développement et Intégration d'un microservice de gestion de documents numériques
dans une plateforme académique. Sa rédaction n’a pas été de toute aisé, toutefois, grâce à la
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim III

disponibilité de certains personnes qui ont bien voulu nous inspirer, nous orienter dans nos
recherches, nous fournir des informations, nous encadrer, nous donner des conseils, la
présente étude a été possible. C’est pourquoi, dans l’impossibilité de citer ici tous ceux qui
ont apporté leurs pierres à l’édifice, nous voudrions témoigner notre profonde gratitude,
spécialement a :
M. TEJIOGNI MARC notre encadreur académique à l’IUEs/INSAM pour ses
nombreux conseils et sa disponibilité.
Dr FOYET promoteur de l’institut universitaire de l’IUEs/INSAM.
M. LIONEL MUNKABU, gestionnaire d’entreprise chez Afriland First Bank, pour
m’avoir suivie pendant mon stage.
Toute la team Alt-plus : Pour le l’initialisation et la mise sur pied du projet ;
M. MOUNPOU AROUNA mon papa adoré qui a toujours été là pour moi et qui a dû
supporter tous mes mœurs ;
MAGOUM Angèle ma maman chérie pour ses multiples conseils, son soutien et pour
avoir été toujours là pour moi quand et où il fallait ;
Toute ma famille pour l’assistance et les multiples conseils répètes ;
Tous mes camarades de promotion d’INSAM GL, en particulier pour leur
collaboration ;
À tous mes amis qui de près ou de loin ont contribué à l’élaboration de ce projet.
SOMMAIRE
EPIGRAPHIE.............................................................................................................................ii
DEDICACE...............................................................................................................................iii
REMERCIEMENTS..................................................................................................................iv
SOMMAIRE...............................................................................................................................v
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim IV

AVANT PROPOS.....................................................................................................................vi
RESUME..................................................................................................................................vii
ABSTRACT............................................................................................................................viii
LISTE DES ABREVIATIONS.................................................................................................ix
LISTE DES FIGURES...............................................................................................................x
LISTE DES TABLEAUX.........................................................................................................xi
INTRODUCTION GENERALE................................................................................................1
PARTIE I : PRESENTATION DE L’ENTREPRISE, DEROULEMENT DU STAGE ET
GENERALITES.........................................................................................................................3
CHAPITRE I : PRESENTATION DE L’ENTREPRISE, DEROULEMENT DU STAGE
ET GENERALITES................................................................................................................4
CHAPITRE II : GENERALITES SUR LA GESTION DE DOCUMENTS NUMERIQUE
DANS LES UNIVERSITES...................................................................................................9
PARTIE II : CAHIER DE CHARGES, ANALYSE, CONCEPTION ET
IMPLEMENTATION...............................................................................................................11
CHAPITRE III : CAHIER DES CHARGES ET ANALYSE DE L’EXISTANT................12
CHAPITRE IV : CONCEPTION ET IMPLEMENTATION...............................................24
CONCLUSION GENERALE..................................................................................................xlv
REFERENCES.......................................................................................................................xlvi
TABLE DE MATIERES.......................................................................................................xlvii
AVANT PROPOS
Crée l’arrêté ministériel N°05/0028/MINESUP du 12 janvier 2005, l’institut
universitaire de l’estuaire (IUEs/INSAM), est un établissement privé d’enseignement
supérieur dont l’objectif est de former les étudiants en vue de l’obtention :
Du Brevet de Techniciens Supérieur (BTS)
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim V

Du Diplôme Supérieur des Études Professionnelles (DSEP)

De la Licence Professionnelle
Des Diplômes Universitaires à travers la formation à distance
Cependant la formation des étudiants à IUEs/INSAM en cycle LICENCE s’étend sur un
an pour toutes les filières donc les spécialités sont organisées de manière suivante :
INDUSTRIELLLE ET TECHNOLOGIE
Réseau et Télécommunication
Informatique Industrielle
Maintenance des Systèmes Informatique
COMMERCE ET GESTION
Gestion des Systèmes d’Information
Comptabilité et Gestion des Entreprises
Action Commerciale
Gestion Logistique et Transport
Commerce Internationale
Pour une formation complète de l’apprenant en cycle Licence Professionnelle, un stage
de perfectionnement est autorisé en entreprise dans le souci d’asseoir les connaissances
théoriques acquises pendant l’année académique. Cependant au terme de ce stage, nous
devons
présenter un rapport de stage au cour d’une soutenance devant un jury d’examen.
C’est dans cette optique des choses, que j’effectue un stage professionnel dans l’entreprise
Afriland First Bank dont le thème est : développement et intégration d'un microservice
de gestion de documents numériques dans une plateforme académique.
RESUME
Ce rapport de stage de licence porte sur le développement et l'intégration d'un

microservice de gestion de documents numériques dans une plateforme de gestion des
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim VI

activités académiques. La mission consistait à concevoir et développer un microservice

permettant de stocker, de partager et d'organiser les documents liés aux activités académiques
des étudiants et des enseignants. L'architecture logicielle a été conçue pour répondre aux
besoins de la plateforme de gestion, avec une attention particulière portée à la scalabilité, la
sécurité et la performance. Le microservice a été développé en utilisant des technologies
modernes telles que Node.js et MongoDB, puis intégré à la plateforme de gestion existante
via des API RESTful. Des tests ont été effectués pour s'assurer que le microservice répondait
aux exigences fonctionnelles et non fonctionnelles. Ce stage a permis d'améliorer les
compétences en développement logiciel, en gestion de projet et en travail en équipe, tout en
comprenant l'importance de la gestion de documents numériques pour les institutions
académiques.
ABSTRACT
This report aims to summarize a bachelor's degree internship that focused on

developing and integrating a digital document management microservice into an academic
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim VII

activities management platform. The main objective was to design and develop a microservice
capable of storing, sharing, and organizing documents related to academic activities of
students and teachers. The software architecture was designed to address the platform's needs,
with particular attention given to scalability, security, and performance. The microservice was
developed using modern technologies such as Node.js and MongoDB and integrated into the
existing management platform through RESTful APIs. Testing was conducted to ensure that
the microservice met the functional and non-functional requirements. The internship helped
improve skills in software development, project management, and teamwork while also
highlighting the importance of digital document management for academic institutions.
LISTE DES ABREVIATIONS
MOA : Maître d’ouvrage

MOE : Maître d’œuvre
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim VIII

FC : Fonction Contraint
FP : Fonction Principale
UML : Unified Modeling Language.
SASS : Syntactically awesome stylesheets
API : Application Programing interface
JSX : JavaScript XML.
JSON : JavaScript Object Notation
MERN : Mongo, Express, React, Node.
EME : Elément du Milieu Extérieur
SGBD : Système de Gestion de Base de Données
SQL : Structured Query Language
NoSQL : not only SQL
EDI : Environnement de Développement Intégré
LISTE DES FIGURES
Figure 1 : Plan de localisation Afriland First Bank....................................................................6

Figure 2 : Organigramme Afriland First Bank Bafoussam.........................................................7
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim IX

Figure 3: Bêtes à cornes............................................................................................................17

Figure 4 : Diagramme pieuvre..................................................................................................18
Figure 5 : Réseau PERT............................................................................................................20
Figure 6 : Diagramme de GANTT............................................................................................20
Figure 7 : Diagramme de cas d’utilisation................................................................................26
Figure 8 : Diagramme de séquence - Gestion des droits d’accès.............................................30
Figure 9 : Diagramme de classe................................................................................................31
Figure 10 : SCRUM..................................................................................................................34
Figure 11 : Modèle REST.........................................................................................................36
Figure 12 : Git Flow..................................................................................................................41
Figure 13 : Interface de connexion...........................................................................................42
Figure 14 : Interface vue d’ensemble (Accueil).......................................................................43
Figure 15 : la page libraires......................................................................................................44
Figure 16 : la page profil utilisateur..........................................................................................45
LISTE DES TABLEAUX
Tableau 1 : Les parties prenantes du projet..............................................................................14

Tableau 2 : Les moyens de communication..............................................................................15
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim X

Tableau 3 : Organigramme des tâches......................................................................................18

Tableau 4 : Ressources matérielles...........................................................................................20
Tableau 5 : Ressources logicielles............................................................................................21
Tableau 6 : Modèle de base COCOMO....................................................................................22
Tableau 7 : Bilan pour l'estimation des coûts du projet............................................................23
Tableau 8 : Modèles de cycle de vie.........................................................................................32
Tableau 9 : Modèles d’architecture...........................................................................................35
Tableau 10 : liste des langages de programmation...................................................................38
Tableau 11 : Environnement de développement intégré (EDI)................................................39
INTRODUCTION GENERALE
L'essor des technologies de l'information et de la communication a permis aux

institutions académiques de développer des solutions innovantes pour gérer leur
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XI

fonctionnement. Dans ce contexte, l'architecture microservices est de plus en plus utilisée

dans les universités pour concevoir des applications modulaires et évolutives. Pendant mon
année de licence en génie logiciel, j'ai eu l'opportunité de participer à la conception et au
développement d'une application complète basée sur l'architecture microservices pour une
université.
Au cours de mon stage professionnel à Afriland First Bank, j'ai été exposé à l'importance
de la numérisation des documents dans la gestion des activités d'une entreprise. Cela m'a
amené à proposer l'ajout d'un microservice de numérisation de documents dans l'application
de gestion des activités académiques pour mon institut universitaire.
Plus spécifiquement, j'ai travaillé sur le microservice de gestion de documents numériques

de l'Institut. Ce microservice permet de centraliser et de gérer les ressources académiques
telles que les supports de cours, les anciennes épreuves d'examen et les rapports de stage.
Au cours de mon stage, j'ai également participé au développement d'autres microservices au
sein de l'application. Cependant, ce rapport se concentrera sur la partie gestion des documents
numériques, en décrivant en détail le processus de conception et de développement de ce
microservice, en mettant l'accent sur les choix techniques, les défis rencontrés et les solutions
mises en place. Pour atteindre nos objectifs. Le présent rapport sera structuré en quatre (4)
grands chapitres couvrant l’ensemble des aspects de notre travail :
 1er Chapitre, présentation de l’entreprise et déroulement du stage : nous ferons une

présentation globale de l’entreprise et nous y indiquerons notre insertion dans la
structure.
 2ème Chapitre, généralités : nous présenterons de manière globale en quoi consiste le

thème de notre rapport de stage à l’échelle universelle.
 3ème Chapitre, cahier des charges et analyse de l’existant : nous parlerons ici des
différents besoins liés à cette tâche et des méthodes utilisées au sein de l’entreprise.
 4ème Chapitre, conception et implémentation : ici, nous montrerons ce que l’on a

prévu pour éliminer les défaillances du système de gestion déjà en place, en essayant
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XII

de le rendre plus efficace, en proposant de nouvelles approches ainsi que les résultats
de notre travail.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XIII

PARTIE I : PRESENTATION
DE L’ENTREPRISE,
DEROULEMENT DU STAGE
ET GENERALITES
CHAPITRE I : PRESENTATION DE
L’ENTREPRISE, DEROULEMENT DU
STAGE ET GENERALITES
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XIV

I. PRESENTATION DE L’ENTREPRISE
I.1. Historique
Afriland First Bank Cameroun a été créée en 1987 sous le nom de Caisse Commune
d'Epargne et d'Investissement (CCEI). En 1997, elle est rachetée par le groupe Afriland First
Bank, qui lui donne son nom actuel. Depuis lors, Afriland First Bank Cameroun a connu une
croissance rapide et est devenue l'une des principales banques du pays.
En 2011, Afriland First Bank Cameroun a été la première banque du pays à lancer une
carte bancaire VISA prépayée, ce qui a contribué à améliorer l'accès aux services bancaires
pour les Camerounais qui n'ont pas de compte bancaire.
En 2014, Afriland First Bank Cameroun a ouvert une agence à Bafoussam, dans la
région de l'Ouest du Cameroun. Cette agence offre des services bancaires à une population
locale qui a besoin de services bancaires de qualité.
Afriland First Bank Cameroun s'est également engagée dans des initiatives de
responsabilité sociale d'entreprise, notamment en soutenant des projets éducatifs et en
fournissant un accès aux services financiers pour les populations rurales et défavorisées.
Aujourd'hui, Afriland First Bank Cameroun continue d'étendre sa présence dans le pays et de
développer ses services bancaires pour répondre aux besoins de ses clients.
I.2. Plan de localisation

Afriland First Bank Bafoussam est située sur le marché A de la ville de Bafoussam,
dans la région de l'Ouest du Cameroun. Le marché A est l'un des marchés les plus importants
de la ville, avec une grande concentration d'activités commerciales et économiques. Cette
localisation stratégique permet à la banque de bénéficier d'un emplacement central dans la
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XV

ville et de se rapprocher de ses clients, notamment les commerçants et les entrepreneurs

locaux. De plus, la banque est facilement accessible par les transports en commun et dispose
d'un parking pour les clients qui viennent en voiture.
Figure 1 : Plan de localisation Afriland First Bank
I.3. Organigramme
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XVI

Directeur
regional
Directeur
D'agance
gestionnaire Gestionnaire chef des Secrétaire

d'entreprise Particulier operations d'agance
Chef service Caissières

courier
Stagiaires techniciens
de surface
Figure 2 : Organigramme Afriland First Bank Bafoussam
II. DEROULEMENT DU STAGE
Mon stage a été effectué dans le cadre de ma formation en licence génie logiciel. J'ai
effectué un stage professionnel de 3 mois à Afriland First Bank en tant qu'assistant du chef
des opérations bancaires. Au cours de ce stage, j'ai pris conscience de l'importance de la
gestion numérique des documents dans les structures et j'ai décidé d'améliorer celle de mon
établissement scolaire. Pour cela, j'ai choisi comme thème de mon rapport de stage :
développement et Intégration d'un microservice de gestion de documents numériques
dans une plateforme académique.
II.1. Accueil
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XVII

Lors de mon arrivée chez Afriland First Bank, j'ai été accueilli par l'équipe du
service des opérations bancaires. Ils m'ont présenté les différents membres de l'équipe ainsi
que les différents projets en cours. J'ai également eu une visite des locaux et des équipements
mis à ma disposition pour la réalisation de mon stage en tant qu'assistant du chef des
opérations bancaires.
II.2. Activités du stagiaire
Durant mon stage à Afriland First Bank, j'ai travaillé en tant qu'assistant du chef des
opérations bancaires. Mes activités principales ont été la gestion des opérations bancaires,
notamment la vérification des données numériques pour les transferts de fonds nationaux et la
télé-compensation des chèques provenant d'autres banques.
Après mon stage, j'ai travaillé avec l'équipe de ma startup de service informatique,
Alt-Plus, sur une plateforme de gestion des activités académiques. Au cours du
développement de cette plateforme, j'ai décidé d'intégrer un microservice de gestion de
documents numériques. Pour cela, j'ai effectué les activités suivantes :
Analyse des besoins : j'ai commencé par comprendre les besoins des utilisateurs de la
plateforme en matière de gestion de documents numériques. J'ai mené des entretiens
avec les différents acteurs de l'établissement scolaire pour identifier les problèmes
rencontrés dans la gestion des documents.
Conception du microservice : une fois les besoins identifiés, j'ai conçu le

microservice. J'ai défini les fonctionnalités nécessaires, les interfaces avec les autres
services de la plateforme et les technologies à utiliser.
Développement du microservice : j'ai ensuite développé le microservice en utilisant

les technologies choisies. J'ai respecté les bonnes pratiques de développement et utilisé
des outils de gestion de code source pour assurer la qualité du code.
Intégration du microservice : une fois le microservice développé, j'ai procédé à son

intégration dans la plateforme de gestion des activités académiques que nous étions en
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XVIII

train de développer. J'ai testé le microservice pour m'assurer qu'il fonctionnait

correctement avec les autres services de la plateforme.
Documentation et formation : enfin, j'ai rédigé la documentation technique du

microservice et formé les autres membres de l'équipe à son utilisation. J'ai également
rédigé un rapport de stage pour présenter les différentes étapes de mon travail et les
résultats obtenus.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XIX

CHAPITRE II : GENERALITES SUR LA

GESTION DE DOCUMENTS NUMERIQUE
DANS LES UNIVERSITES
Dans cette section, nous allons définir la gestion de documents numériques, en

expliquant sa pertinence pour les institutions académiques, notamment les universités. Nous
démontrerons également l'importance de la gestion de documents numériques pour la
conservation, la sécurité et la disponibilité des documents numériques pour les utilisateurs
autorisés. Nous expliquerons également comment la gestion de documents numériques peut
améliorer la productivité et l'efficacité des opérations universitaires.
I. DEFINITION
La gestion de documents numériques dans les universités consiste à stocker, gérer,
organiser et distribuer les documents numériques utilisés dans les activités académiques. Elle
permet de faciliter l'accès aux informations, d'améliorer la productivité et l'efficacité des
opérations universitaires et de permettre une collaboration plus efficace.
Stockage des documents numériques : Les documents peuvent être stockés sur des
serveurs locaux, des disques durs externes, des services de cloud computing ou une
combinaison de ces options.
Gestion des versions des documents numériques : Elle permet de suivre les
modifications apportées aux documents et de s'assurer que les utilisateurs accèdent à la
version la plus récente du document.
II. POURQUOI NUMERISER LES DOCUMENTS D'UNE

UNIVERSITE ?
La numérisation des documents d'une université permet de faciliter l'accès aux

informations, de réduire les coûts de stockage et d'archivage, d'améliorer la recherche et
l'analyse de l'information, et de réduire l'empreinte carbone.
Numérisation des documents papier : Les documents papier peuvent être numérisés
à l'aide d'un scanner ou d'un photocopieur équipé d'une fonction de numérisation.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XX

Gestion des documents numériques : Les documents numériques doivent être

organisés de manière logique, étiquetés et stockés dans un système de gestion de
documents numériques.
III. SECURITE ET CONFIDENTIALITE

La sécurité et la confidentialité des documents numériques sont essentielles pour
protéger les informations sensibles et confidentielles. Les universités peuvent mettre en place
des mesures de contrôle d'accès, des politiques de sécurité des données et des processus de
sauvegarde réguliers.
Contrôle d'accès : Les universités peuvent utiliser des systèmes d'authentification

pour garantir que seuls les utilisateurs autorisés ont accès aux documents numériques.
Politiques de sécurité des données : Les politiques peuvent inclure des mesures de
sécurité telles que la classification des données, la gestion des mots de passe, la
surveillance des activités utilisateur et la limitation des accès.
Processus de sauvegarde : Les universités peuvent mettre en place des processus de

sauvegarde réguliers pour assurer la disponibilité des données en cas de perte de
données ou de corruption de fichiers.
IV. CONCLUSION
La gestion de documents numériques dans les universités nécessite une planification

minutieuse, une organisation efficace et des mesures de sécurité adéquates. Les avantages de
la numérisation des documents papier sont nombreux, notamment la réduction des coûts et la
facilitation de l'accès à l'information. Les universités doivent être conscientes des risques
associés à la gestion de documents numériques et mettre en place des mesures de sécurité
robustes pour protéger les données confidentielles et garantir la disponibilité des données en
cas de sinistre.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXI

PARTIE II : CAHIER DE
CHARGES, ANALYSE,
CONCEPTION ET
IMPLEMENTATION
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXII

CHAPITRE III : CAHIER DES CHARGES ET

ANALYSE DE L’EXISTANT
I. PRESENTATION DU PROJET
Dans ce chapitre, nous allons présenter le cahier des charges de notre projet. Nous
allons notamment décrire les fonctionnalités attendues du système de gestion de documents
numériques et les exigences en matière de sécurité et de confidentialité des données.
I.2. Etat De L’existant

Les universités utilisent souvent des systèmes de gestion de documents numériques
pour stocker et organiser les documents, mais ces systèmes peuvent présenter des lacunes en
matière de sécurité et de confidentialité des données. Certains documents sont encore stockés
sous forme papier, ce qui rend leur gestion plus complexe et moins efficace. Il est important
de centraliser les données numériques pour une gestion plus efficace et pour faciliter l'accès
aux informations.
I.3. Limites de l’existant

Actuellement, la gestion des documents numériques dans les universités est souvent
inefficace et informelle, avec des documents distribués de manière variée et souvent via des
réseaux sociaux. Cela peut entraîner des problèmes tels que la perte de documents importants,
le manque de sécurité et de confidentialité, ainsi que des difficultés pour les étudiants et le
personnel enseignant à trouver rapidement les documents dont ils ont besoin.
I.4. Proposition De Solution

Pour remédier à ces problèmes, il est proposé de développer un microservice de
gestion de documents numériques centralisé et sécurisé, intégré à la plateforme de gestion des
activités académiques. Ce microservice permettra aux utilisateurs de stocker, rechercher et
récupérer facilement des documents numériques tels que des rapports de stage, des supports
de cours, des anciennes épreuves d'examens, etc. Le microservice devra offrir des
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXIII

fonctionnalités de sécurité robustes pour garantir la confidentialité et l'intégrité des documents

stockés, ainsi que des fonctionnalités de recherche avancées pour permettre aux utilisateurs de
trouver facilement les documents dont ils ont besoin.
En développant un microservice de gestion de documents numériques centralisé et

sécurisé, les universités pourront faciliter la gestion des documents numériques, améliorer la
sécurité et la confidentialité, et offrir une expérience utilisateur moderne et intuitive.
I.5. Les besoins ou fonctionnalités attendues

I.51. Besoins fonctionnels
Les besoins fonctionnels listent les opérations réalisables avec l’application.

L’application permettra donc :
Permettre l'upload de documents numériques depuis la plateforme.
Stocker les documents numériques de manière sécurisée et accessible pour les
utilisateurs autorisés.
Permettre la recherche, la consultation et le téléchargement des documents numériques
en fonction de différents critères d’accessibilité.
Permettre la gestion des autorisations d'accès aux documents numériques en fonction
des rôles des utilisateurs.
Permettre la modification et la suppression des documents numériques par les
utilisateurs autorisés.
Assurer la compatibilité avec différents types de fichiers numériques couramment
utilisés dans les activités académiques tels que les fichiers PDF, Word.
I.5.2. Besoins non fonctionnels
En plus des besoins fonctionnels listés plus haut notre application devra répondre aux
critères suivants :
L’ergonomie : l’application doit être adaptée aux besoins de l’utilisateur qui ne devra
pas fournir d’effort pour utiliser l’application.
La robustesse : la capacité de l’application à gérer les imprévues.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXIV

Scalabilité: capacité de faire évoluer le système sans impacter la performance et la

disponibilité du service.
Maintenabilité : la capacité pour l’application à être maintenus, de manière cohérente
et à moindre coût, en état de fonctionnement.
Sécurité : la capacité de l’application à résister aux attaques.
Multiplateforme : Elle pourra s’adaptée à différents supports tels que ; mobiles, PC,
et tablettes.
I.6. Population cible
Il s’agit ici de l’ensemble des entités qui seront amenées à utiliser l’application. Dans
ce cas, il s’agit des enseignants, des étudiants, des membres du personnel administratif et tous
les acteurs impliqués dans les activités académiques.
I.7. Périmètre du projet
Le périmètre de notre projet se limite au développement et l’intégration d'un

microservice de gestion de documents numériques dans une plateforme de gestion des
activités académiques, au déploiement de celle-ci et à la formation du personnel.
I.8. Définition des parties prenantes du projet
Noms Rôles Description du rôle et niveau Fonctions

d’intervention
Team ALT- Maître d’ouvrage Fournir et contrôle la pertinence Start-Up de
PLUS (MOA) des informations et veille à développement
l’étroite collaboration avec les logiciel et solutions
fournisseurs d’informations. informatiques
M. TEJIOGNI Encadreur Supervise l’évolution du projet Enseignant
Marc académique (phase conception et réalisation en permanent à
particulier) l’IUES/INSAM
M. NJIKAM Analyste Analyse, organise et exécute le Etudiante à
MOUNPOU programmeur projet l’IUES/INSAM
Mohamed
Salim
Tableau 1 : Les parties prenantes du projet
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXV

I.9. Moyens de communication
Dans l’objectif d’élabore un travail efficace, le travail en équipe est un moyen de

fonctionnement qui permet la complémentarité des compétences, de prendre de meilleures
décisions et mieux pouvoir analyser les conséquences des décisions avant de les mettre en
œuvre. Ainsi les stratégies de communication définies dans ce projet sont les suivantes :
Phases Personnes ressources Moyens de communication
Analyse et Analyste programmeur, Encadreur Réunions, questionnaires ,

spécifications des académique, Encadreur professionnel, emails professionnels et
besoins liés au projet MOA meeting en line
Conception Analyste programmeur, Encadreur UML et MERISE, Win’
académique, Encadreur professionnel, design, visual paradigm
MOA
Implémentation Analyste programmeur Programmation
Hybride(JavaScript,
SCSS/SASS, nodeJS,
express.js, electron.js,
reactJS, reactnative),
mongoDB
Mise en production Analyste programmeur Serveur Web (Nodemon,
ou mise en œuvre node, heroku) et le réseau
informatique.
Tableau 2 : Les moyens de communication
I.10. Les livrables liés au projet
Un livrable représente le résultat attendu d’un effort effectué. Comme livrables liées
au projet on a :
 Le cahier des charges fonctionnel : qui mets en exergue les besoins de l’université
et le budget lié au projet ;
 Le cahier technique : qui fournit des informations détaillées au niveau de l’analyse,
la conception et de l’architecture de déploiement de la plateforme.
 Le fichier d’accès: qui contient les information de connexion à la plateforme
d’administration de l’application réalisée.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXVI

 Le manuel d’utilisation (documentation) : qui décrit comment utiliser l’application

réalisée et qui interviendra au niveau de la formation du personnel.
I.11. Analyse fonctionnelle externe
Ici, nous mettrons en exergue l’analyse fonctionnelle du système à travers deux

aspects, Cette analyse fonctionnelle concerne l'usage d'un produit, c'est à dire les fonctions qui
doivent être assuré pour satisfaire le besoin du client. Nous allons donc expérimenter deux
méthodes à savoir :
I.11.1. Bêtes à cornes
Pour formaliser l’énoncé du besoin, l’utilisation de l’outil bête à cornes est le mieux
adapté. Pour cela, il est fondamental de se poser les trois questions suivantes :
 À qui rend-il service ?
 Sur quoi agit-il ?
 Dans quel but le produit existe-il ?
Figure 3: Bêtes à cornes
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXVII

I.11.2. Diagramme pieuvre
Le diagramme pieuvre est un diagramme qui présente les relations entre les différents
éléments du milieu extérieur (EME : ce sont les Éléments du Milieu Extérieur interagissant
avec le produit) et service à l’aide des fonctions : fonctions principales (FP : est la raison
d’être du logiciel) et fonctions de contraintes (FC : ce sont les limitations à mon imagination).
Pour la représentation de notre diagramme pieuvre les éléments du milieu extérieur

seront représenté par les ellipses autour d’une ellipse principale qui représente le logiciel et
les fonctions principales seront représentées pas une ligne passant par le logiciel et reliant
deux ellipses et les fonctions contraintes relient en une ligne les ellipses restant du milieu
extérieur.
Utilisateurs (Team
documents
Documents Personnel
Manager, et de
Assistante
étudiants
service)
FP1
FC4
gestion électronique
Archivage numérique
des documents
FC1
académiques
FC3
Portabilité Environnement de
FC2
déploiement
Sécurité des données
Figure 4 : Diagramme pieuvre
Fonctions principales (FP) Fonctions contraintes (FC)
FP1 : Permettre la gestion FC1 : Adapter la solution à tout type de périphérique

électronique des documents
académiques FC2 : Assurer la confidentialité des données
FC3 : Faciliter l’accessibilité à la solution
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXVIII

II.12. Planification du projet

II.12.1. Organigramme des tâches
TACHES N° TACHE TACHES DUREE

ANTERIEURES (JOURS)
Entretien avec la MOA A 1
Étude de faisabilité B A 2
Analyse des besoins C B 5
Analyse de l’existant D B 3
Rédaction et validation du cahier des E C, D 8

charges
Conception F E 14
Implémentation G F 20
Tests et validation H F 21
Déploiement I H, G 2
Formation du personnel J I 1
Tableau 3 : Organigramme des tâches
Durée du projet : 54 Jours (Du 09/06/2023 Au 02/08/2023).
II.12.2. Réseau ou méthode PERT
Le réseau PERT (Program Evaluation and Review Technique ou Technique

d’Évaluation et d’Examen de Programme) : C’est une méthode conventionnelle utilisable
en gestion de projet, ordonnancement et planification développée aux États-Unis par la
marine américaine dans les années 1950.La méthode PERT permet de représenter la
planification de la réalisation d’un projet suivant un graphe de dépendances.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXIX

Figure 5 : Réseau PERT
II.12.3. Diagramme de GANTT
Le diagramme de Gantt est un outil utilisé (souvent en complément d’un réseau

PERT) en ordonnancement et en gestion de projet et permettant de visualiser dans le temps les
diverses tâches composant un projet.
À partir de résultats obtenus du réseau PERT, plus les hypothèses sur la ressource
disponible, on construit un planning (calendrier) sous forme de diagramme dont l’axe des
abscisses représente le temps et l’axe des ordonnées représente les tâches.
Figure 6 : Diagramme de GANTT
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXX

II.13. Estimation du coût du projet

II.13.1. Ressources utilisées
Ressources matérielles
Désignation Caractéristique Utilité dans le Quantité Prix Prix

ou fournisseur projet unitaire total
(FCFA) (FCFA)
PC HP Probook 440 L’implémentation et 01 200000 200000
G1 intel core I5 les tests et validation
4600 2.60hz de l’application
HDD 500Go,
RAM 8Go
Scanner de Résolution Numérisation des 120000

documents - optique : 600 dpi documents physique
portable Couleur
Type d'interface :
USB 2.0
Montant total 320000

Tableau 4 : Ressources matérielles
Ressources logicielles
Désignation Editeur Version Licence Fonction Prix

(FCFA)
Windows Microsoft 21H2 Payant Système 32.800
10professionn d’exploitation
elle
Node - 16.14.0 Gratuit Moteur JavaScript 0
Vs code Microsoft 1.59.0 Gratuit Editeur de texte 0
Ms Project Microsoft 16.0.426 Payant Gestion des 12.500

6 Tâches
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXXI

Mongo - 1.29.5 Gratuit Gérer la base de 0

compass donnée No SQL
PostMan PostMan 9.15 Payant Tester les apéles à
l’API
Serveur VPS OVH - Payant Héberger la 400000
solution sur un
serveur en ligne
Montant total 445.300
Tableau 5 : Ressources logicielles
II.13.2. Estimation de la charge de travail
Il existe des méthodes reconnues et efficients d’estimation des projets informatiques

parmi lesquelles la méthode comparative, la méthode analytique, la méthode DELPHI, et la
méthode COCOMO pour ne citer que ceux-là.
Dans le cadre ce projet, c’est la méthode COCOMO 81 qui a été sollicité pour
l’estimation de ce projet. A l’aide la méthode COCOMO :
 Il est facile à un informaticien d'estimé le nombre de lignes source.
 La complexité d’écriture d’un programme est la même quel que soit le langage de
programmation.
 Il propose une méthode basée sur la corrélation entre la taille d'un projet et sa charge.
Il faut préciser que COCOMO est constitué de trois modèles (base, intermédiaire et
détaillé). Nous utiliserons dans ce projet le modèle de base en raison de sa simplicité
d’implémentation.
Le modèle de base de la méthode COCOMO caractérise chaque type de projet selon le
tableau suivant :
Type de projet Nombre de ligne de Charge en Délai en Mois
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXXII

code Mois/Homme
Simple < 50 000 lignes a=3.2 c=2.5
b=1.05 d=0.38
Moyen 50 000 ≤ lignes ≤300 a=3 c=2.5
000 b=1.12 d=0.35
Complexe > 300 000 lignes a=2.8 c=2.5
b=1.2 d=0.32
Tableau 6 : Modèle de base COCOMO
Les formules
 Charge = a x (ksloc)b
 Délai = c x (charge)d
 Taille moyenne de l’équipe = charge / Délai
Avec :
 KSLOC (Kilo Source Lines Of Code) 1 KSLOC = 1000 lignes de code source
 Les paramètres a, b, c et d qui dépendent de la catégorie du projet.
Nous estimerons le nombre de ligne de code de notre projet à 15.000.

Nous aurons donc :
Charge = 3.2 x (15000/1000)1.05 = 45.04 Mois/Homme
Délai = 2.5 x (45.04)0.38 = 9.65 ≈ 9 Mois 17 Jours
Taille moyenne de l’équipe de réalisation du projet = 45.04 / 9.65 = 4.67 ≈ 05 Hommes
Ainsi, la taille moyenne estimée de l’équipe pour la réalisation du projet de 05 personne
(développeur JavaScript (Full-Stack)) et le temps de réalisation estimé est de 9 Mois 17 Jours.
Une étude menée sur le salaire moyen mensuel d’un développeur Web au Cameroun d’après
le site « localhostkmer.xyz » disponible à l’adresse :
Formation développeur web à Douala au Cameroun - LocalHost Digital - Meilleure Agence
Web et Digitale au Cameroun (11/07/2023) Montre que le salaire moyen mensuel d’un
développeur Web est de 250.000 FCFA/mois. Alors le cout de réalisation du projet en termes
de ressources humaines est de 250.000 * 5 = 1.250.000 FCFA.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXXIII

II.13.3. Bilan
Charges liées au projet Coût (FCFA)

Ressources matérielles 320.000
Ressources logicielles 445.300
Ressources humaines 1.250.000
Total 2.010.300
Imprévus (10% du coût du projet) 201.030
Coût total du projet 2.211.330
Tableau 7 : Bilan pour l'estimation des coûts du projet
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXXIV

CHAPITRE IV : CONCEPTION ET
IMPLEMENTATION
I. CONCEPTION DE LA SOLUTION
I.1. Présentation d’UML
UML (Unified Modeling Language), est un langage de modélisation graphique et

textuelle constitué d’un ensemble de schémas appelés diagrammes, Il est un langage de
modélisation unifié car il est issu de plusieurs diverses méthodes orientées objets. UML est un
langage visuel constitué d’un ensemble de schémas appelés diagrammes, qui donne chacun
une vision différente du projet à traiter. En somme, UML est un langage de modélisation qui
permet de représenter graphiquement les besoins des utilisateurs et offre différentes vues pour
modéliser le système ; IL s’articule actuellement autour de 13 diagrammes différents, dont 4
nouveaux diagrammes introduits par UML 2.0. Par ailleurs, il modélise le système suivant
deux modes de représentation : l’un concerne la structure du système pris « au repos », l’autre
concerne sa dynamique de fonctionnement :
Diagrammes structurels ou diagrammes statiques (UML Structure)
Diagramme de classes (Class diagram)
Diagramme d’objets (Object diagram)
Diagramme de composants (Component diagram)
Diagramme de déploiement (Deployment diagram)
Diagramme de paquetages (Package diagram)
Diagramme de structures composites (Composite structure diagram)
Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)
Diagramme de cas d’utilisation (Use case diagram)
Diagramme d’activités (Activity diagram)
Diagramme d’états-transitions (State diagram)
Diagrammes d’interaction (Interaction diagram)
Diagramme de séquence (Séquence diagram)
Diagramme de communication (Communication diagram)
Diagramme global d’interaction (Interaction overviewdiagram)
Diagramme de temps (Timing diagram)
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXXV

Remarque : Nous tenons vivement à préciser qu’UML n’est pas une méthode
d’analyse mais un langage de modélisation qui est implémenté par des méthodes d’analyse.
Comme méthodes d’analyse implémentant UML on en distingue deux grands groupes les
méthodes unifiées et les méthodes agiles.
I.2. Modélisation avec UML
Modéliser un système d’information permet de mieux comprendre son

fonctionnement. C’est également un bon moyen de maitriser sa complexité et d’assurer sa
cohérence. Focalisée sur le métier de l’utilisateur, cette étape sert à minimiser les risques de
production ne cadrant pas avec les besoins de l’utilisateur.
I.2.1. Diagramme de cas d’utilisation

Les cas d’utilisations décrivent sous la forme d’actions et de réactions, le
comportement d’un système étudié du point de vue des utilisateurs. Ils définissent les limites
du système et ses relations avec son environnement. Il permet de représenter les grandes
fonctionnalités du système et assure la réalisation d’un logiciel qui répond aux attentes des
utilisateurs car son élaboration se fonde sur les entretiens avec les utilisateurs.
Figure 7 : Diagramme de cas d’utilisation
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXXVI

 Description textuelle du cas d’utilisation : Gestion des droits d'accès

Objectif : permettre à l’administrateur du système d’attribuer, de révoquer et
de contrôler les accès aux fonctionnalités du service.
Acteurs concernés : Administrateur de la plateforme.
Précondition : l’administrateur s’est authentifié et possède un jeton (JWT :
Json Web Token) avec le grade admin.
Scenario nominal :
1-a L’administrateur souhaite afficher l’interface d’administration
(dashboard).
 Le système affiche un formulaire d’authentification.
 Le système fait une requête et affiche les données à l’administrateur
authentifier.
Scenario alternatif :
1-a Modification du rôle des utilisateur de la plateforme
 L'administrateur accède à l'interface de gestion des rôles.
 Le système affiche une liste des utilisateurs et des rôles associés.
 L'administrateur sélectionne un utilisateur et modifie son rôle.
 Le système enregistre la modification et envoie une notification à
l'utilisateur concerné.
1-b Attribution des permissions :
 L'administrateur accède à l'interface de gestion des permissions.
 Le système affiche une liste des permissions disponibles et des rôles
associés.
 L'administrateur sélectionne une permission et un rôle, et attribue la
permission au rôle.
 Le système enregistre la modification et envoie une notification aux
utilisateurs concernés.
1-c Révocation des permissions :
 L'administrateur accède à l'interface de gestion des permissions.
 Le système affiche une liste des permissions disponibles et des rôles
associés.
 L'administrateur sélectionne une permission et un rôle, et révoque la
permission du rôle.
 Le système enregistre la modification et envoie une notification aux
utilisateurs concernés.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXXVII

 Description textuelle du cas d’utilisation : Partage de supports de cours et

épreuves
Objectif : permettre aux enseignants de partager des supports de cours et des

épreuves avec les étudiants de manière sécurisée.
Acteurs concernés : enseignants, étudiants.
Précondition : l'enseignant s'est authentifié sur la plateforme et a les

permissions nécessaires pour partager des supports de cours et des épreuves.
Scenario nominal :
1-a L’ enseignants souhaite ajouter une document.

 L'enseignant accède à l'interface de partage de documents.
 Le système affiche une liste des cours enseignés par l'enseignant.
 L'enseignant sélectionne le cours pour lequel il souhaite partager des
documents.
 Le système affiche une liste des documents disponibles pour le cours
sélectionné.
 L'enseignant sélectionne les documents qu'il souhaite partager avec les
étudiants.
 Le système envoie une notification aux étudiants inscrits au cours,
indiquant que de nouveaux documents sont disponibles.
 Les étudiants peuvent accéder aux documents partagés via leur compte
utilisateur.
1-a. Suppression de documents partagés :

 L'enseignant accède à l'interface de gestion de partage de documents.
 Le système affiche une liste des documents partagés par l'enseignant.
 L'enseignant sélectionne les documents qu'il souhaite supprimer.
 Le système supprime les documents sélectionnés et envoie une
notification aux étudiants concernés.
1-b. Modification de documents partagés :

 L'enseignant accède à l'interface de gestion de partage de documents.
 Le système affiche une liste des documents partagés par l'enseignant.
 L'enseignant sélectionne le document qu'il souhaite modifier.
 Le système permet à l'enseignant de modifier le document sélectionné
et enregistre les modifications.
 Le système envoie une notification aux étudiants concernés indiquant
qu'une nouvelle version du document est disponible.
 Description textuelle du cas d’utilisation : Partage de rapport de stage
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXXVIII

Objectif : permettre aux étudiants de partager leurs rapports de stage avec leurs
tuteurs de stage et leurs enseignants de manière sécurisée.
Acteur concerné : étudiants.
Précondition : l'étudiant s'est authentifié sur la plateforme et a les permissions
nécessaires pour partager des rapports de stage.
Scenario nominal :
1-a l’étudiant veux ajouter son rapport sur la plateforme
 L'étudiant accède à l'interface d'ajout de rapports de stage.
 Le système affiche un formulaire d'ajout de rapport de stage.
 L'étudiant remplit les champs du formulaire avec les informations
nécessaires (nom du rapport, entreprise d'accueil, période de stage,
etc.).
 L'étudiant téléverse le rapport de stage au format PDF et/ou Word.
 Le système vérifie que le rapport de stage est bien au format attendu et
enregistre le rapport de stage dans la base de données.
1-a Modification de rapports de stage ajoutés
 L'étudiant accède à l'interface de gestion de rapports de stage.
 Le système affiche une liste des rapports de stage ajoutés par l'étudiant.
 L'étudiant sélectionne le rapport de stage qu'il souhaite modifier.
 Le système permet à l'étudiant de modifier le rapport de stage

sélectionné et enregistre les modifications.
 Le système envoie une notification au tuteur de stage et à l'enseignant

concernés indiquant qu'une nouvelle version du rapport de stage est
disponible.
I.2.2. Diagramme de séquence
Le diagramme de séquence permet de représenter les interactions entre objets en indiquant la

chronologie des échanges. Cette représentation peut se réaliser par cas d’utilisation en
considérant les différents scénarios associés. La réalisation d’un bon digramme de séquence
fait également intervenir trois concepts :
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XXXIX

 Ligne de vie : Dans ce cas l’émetteur reste en attente de la réponse à son message
avant de poursuivre ses actions.
 Message synchrone : Dans ce cas l’émetteur reste en attente de la réponse à son
message avant de poursuivre ses actions.
 Message asynchrone : Dans ce cas, l’émetteur n’attend pas la réponse à son message.
Cas de gestion des droits d’accès
Figure 8 : Diagramme de séquence - Gestion des droits d’accès
I.2.3. Diagramme de classe
Le diagramme de classe constitue l’un des pivots essentiels de la modélisation avec

UML. En effet, ce diagramme permet de donner la représentation statique du système à
développer. Cette représentation est centrée sur les concepts de classe et d’association.
Chaque classe se décrit par les données et les traitements dont elle est responsable pour elle-
même et vis-à-vis des autres classes. Les traitements sont matérialisés par des opérations. Le
détail des traitements n’est pas représenté directement dans le diagramme de classe ; seul
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XL

l’algorithme général et le pseudo code correspondant peuvent être associés à la modélisation.

La description du diagramme de classe est fondée sur :
 Le concept d’objet ;
 Le concept de classe comprenant les attributs et les opérations ;
 Les différents types d’association entre classes.
Figure 9 : Diagramme de classe
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLI

II. IMPLEMENTATION DE LA SOLUTION
La mise sur pied d’une solution informatique une fois la conception terminée ne pose
quasiment pas de réels problèmes ; du moins lorsque les outils choisis pour l’implémentation
et le modèle de processus adopté sont adéquats. Pour passer à l’implémentation, il est donc
important d’effectuer un choix judicieux des différents éléments, afin de rester productif et
fidèle au plan conceptuel préalablement fixé.
II.1. Choix du modèle de cycle de vie
Un modèle de cycle de vie est une représentation abstraite d’un ensemble structuré
d’activités nécessaires pour le développement d’un logiciel. Ils en existent une panoplie,
différents par la taille de l’équipe engagée dans le projet, les besoins du client, le temps
imparti et le budget alloué. Cependant, tous sont structurés pour permettre la production d’un
logiciel de qualité, fidèle aux spécifications de départ. Entre spécification, conception,
implémentation, validation, amélioration ou maintenance, les modèles de processus visent à
accroître la productivité des équipes de développement. Le tableau ci-dessous essaie de
présenter différents modèles de processus parmi les plus connus avec leurs avantages et
inconvénients.
Modèles Avantages Inconvénients

Cascade Produit des livrables définis au Découverte d’une erreur entraine
préalable, se termine à une date retour à la phase à l’origine de
précise l’erreur, cout de médiation d’une
erreur important donc choix en
amont cruciaux
V Simple et intuitive à utiliser, Processus lourd et difficile de
marche bien pour les petits projets revenir en arrière, nécessite des
spécifications précises et stables
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLII

Spirale Possibilité d’adaptation en cas de Gestion plus complexe du projet, la

changement des spécifications, le fin du projet n’est pas très vite
développement peut être divisé en perceptible, onéreux pour de petits
petites parties, meilleure gestion projets, la spirale peut ne pas
des risques s’achever
Itératif Résultats périodiques, possibilité Requiert d’importantes ressources,
de développement parallèle, faible difficile de changer les
coût de changement, test et spécifications initiales malgré la
débogage continu, meilleure facile adaptation au changement,
analyse des risques requiert beaucoup d’attention
managériale, incompatible aux
petits projets
RAD (Rapid Favorable au changement de Dépend de l’habilité technique de
Application spécifications, mesure de l’équipe à détecter des outils
Development) l’évolution, évolution rapide en cas puissants, seul les systèmes
d’utilisation de puissants outils, modulables peuvent être
productif avec un faible effectif, développés avec ce modèle,
temps de développement réduit, requiert des développeurs et
encourage la réutilisation des concepteurs hautement qualifiés,
composants complexité de management,
adéquat pour les systèmes orientés
composant et scalables
SCRUM Approche très réaliste pour le Pas favorable à la gestion de
développement logiciel, encourage dépendances complexes, risques
le travail en équipe, possibilité de élevés de maintenance et
développement et de démonstration d’extensibilité, dépend de
rapide des fonctionnalités, l’interaction avec le client, manque
ressources requises minimales, de documentation donc difficulté
favorable au changement de de transfert technologique à une
spécifications. nouvelle équipe
Tableau 8 : Modèles de cycle de vie
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLIII

À la vue de ce tableau, on observe que, la structure de l’équipe engagée dans le

développement, le temps alloué, le budget, les contraintes de livraison et les compétences
techniques sont importantes pour fixer le choix du modèle de processus à adopter. En effet,
pour la réussite de ce projet, le travail en équipe et les démonstrations ont été sollicités pour
fournir une solution de qualité supérieure. De plus le cadre de travail doit permettre de
répondre à des problèmes complexes, tout en livrant de manière productive et créative des
produits de la plus grande valeur possible.
Pour parfaire notre travaille nous avons choisis d’utiliser la méthode SCRUM
encourage grandement le travail en équipe.
Figure 10 : SCRUM
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLIV

II.2. Choix des patrons de conception (design patterns)
Les modèles d’architecture ont été développés pour structurer l’application

développée. Ils permettent de décomposer l’application en plusieurs modules ayant chacun un
rôle qui lui est attribué.
Modèles Avantages Inconvénients
ARCH Adapté aux interfaces à base de Il est abstrait car il ne précise pas
menus et d’écrans de saisie. Il dé- comment réaliser les différentes
compose le logiciel en trois (03) parties et leurs interconnexions
couches à savoir : La présentation en utilisant les constructions
pour la vue, l’interface application disponibles dans les langages de
pour convertit les entrées de programmation.
l’utilisateur en appels du noyau
fonctionnel et inversement et le
dialogue pour interconnecter les
couches
MVC (Modèle Vue Apporte une visibilité claire sur L’inconvénient majeur du modèle
Contrôleur) l’architecture du logiciel. Il MVC n’est visible que dans la
simplifie les tâches maintenance réalisation de petits projets, de
et d’amélioration du logiciel. Ainsi sites internet de faible envergure.
le logiciel est décomposé en En effet, la séparation des
trois(03) modules à savoir Le différentes couches nécessite la
modèle pour les données à création de plus de fichiers (3 fois
afficher, la vue pour l’interface plus exactement) : Un fichier pour
graphique et le contrôleur le modèle, un fichier pour le
contenant la logique concernant contrôleur, un fichier pour la vue
les actions effectuées par
l’utilisateur.
REST L'architecture REST ne nécessite Dépendance à HTTP :
(representational aucun langage de description L'architecture REST est basée sur
state transfer) d'interface, comme WSDL, et
le protocole HTTP, ce qui peut
fonctionne parfaitement non
seulement avec le langage XML limiter sa portabilité ou sa capacité
(eXtensible Markup Language), à fonctionner dans des
mais aussi avec JSON (JavaScript
environnements qui n'utilisent pas
Object Notation) et tout autre type
de support que vous souhaitez HTTP.
prendre en charge.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLV

Tableau 9 : Modèles d’architecture

Au vue de ce tableau, il apparaît que la taille du projet, les technologie utilisé, le
périmètre du projet, le temps imparti et la souplesse dans l’organisation du travail sont
importantes pour fixer le choix du modèle de processus à adopter. En effet la réussite de ce
projet passe par une conception claire et efficace, une grande souplesse dans l’organisation du
travail et une intégration des parties prenantes à toutes les étapes du projet qui sont les
principaux « crédo » du modèle REST. Le modèle REST facilite également la réutilisation
de la solution.
Figure 11 : Modèle REST
II.3 – Propositions Et Perspectives

II.3.1 – Cadre De Mise En Œuvre : Atouts / Freins
Notre plateforme a été mise en œuvre grâce notamment aux Framework React pour le
front end, MongoDB et NodeJS pour le back end, Git Kraken pour le versioning, VPS de
OVH pour le déploiement de nos services NodeJS et l’API. L’un ou l’autre possèdent des
limites :
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLVI

II.3.1.1 – ReactJS
Atouts
 Il permet d’utiliser JavaScript : La première de ses particularités est que ce
Framework permet de développer des applications web réactif grâce à la manipulation
du DOM (Document Object Model) à travers un DOM virtuel.
 Un gain de temps considérable : grâce au « hot reload » React permet aux
développeurs de ne plus recompiler mais de recharger l’application
instantanément. Les développeurs gagnent ainsi du temps.
Freins
Malgré ses nombreux avantages, ReactJS présente certains inconvénients qui
pourraient dissuader les développeurs de l’utiliser, à savoir :
 L’inadéquation de JavaScript : qui est un langage qui ne garantit pas contre les
erreurs de programmation.
 Difficulté de s’organiser car React est un Framework qui n’a pas de directives.
II.3.1.2 - MongoDB
Atouts
 Facilité d’expansion : MongoDB s’adapte facilement à la taille
du projet,
Freins
 Interaction entre les documents difficile : il et plus difficile de faire des
interactions entre les documents (Table) car Mongo est basé sur un modèle non
relationnel.
II.3.1.3 – NodeJS
Atouts
 NodeJS est facile à apprendre et ceux qui connaissent déjà JavaScript,
sauront facilement écrire des applications via Node.js.
 Les entreprises admirent la rapidité de NodeJS parce qu’il utilise la version 8
du moteur développé par Google qui compile le code JavaScript en code
machine natif et fonctionne à la vitesse de l’éclair.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLVII

Freins
 Les dépendances : Les dépendances des packages dans le dossier
node_modules ne sont pas toujours à jour.
 Le JavaScript est un langage fort à typage faible, ce qui nécessite un esprit fort
et un certain recul pour faire un travail rigoureux
II.4 – Outils de développement utilisés

II.4.1 – Choix du langage de programmation
Langage Ann Type Paradigme Vitesse Difficulté Multipla Typage

ée s teforme statique
Fortran 1954 Compilé Procédural Moyenne Bonne Possible Non
C 1973 Compilé Procédural Longue Moyenne Possible Oui
C++ 1982 Compilé Procédural, Longue Moyenne Possible Oui

objet,
fonctionnel
Java 1991 Compilé Objet Longue Moyenne Oui Oui
(bytecode)
C# 2000 Compilé Procédurale Longue Moyenne Oui Oui
(bytecode) ,
objet
PHP 1994 Interprété Procédurale Rapide Moyenne Oui Oui
,
objet,
fonctionnel
JavaScript 1995 Interprété Procédurale Rapide Moyenne Oui Oui
,
objet
Python 1991 Interprété Procédurale Rapide Bonne Oui Oui
,
objet,
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLVIII

fonctionnel
Dart 2021 Compilé Objet Rapide Moyenne Oui Oui
(JIT ou
AOT)
Ruby 1993 Interprété Objet Rapide Bonne Oui Oui
Tableau 10 : liste des langages de programmation
À la vue de ce tableau, nous découvrons une multitude de langages de programmation

dont le choix dépend de la solution à mettre sur pied. Le choix d’un langage programmation
dépend non seulement des besoins mais contraintes liés à la réalisation, à la maintenance et à
l’évolutivité de la solution. Ainsi notre choix s’est porté sur le JavaScript car il fournit d’une
part de multiples librairie et Framework permettant de facilité et de réduire le temps de
développement d’autre part il est facilement adaptable pour du multiplateforme.
En plus du JavaScript, la réalisation de la plate-forme à nécessiter l’usage d’autres langages
de programmation au niveau de l’interface utilisateur (GUI) à savoir :
 Le HTML5 (syntaxe JSX) et CSS (avec préprocesseur SASS) pour le contenu
statique de l’application c’est-à-dire le contenu et le design ;
II.3.2. Choix de l’environnement de développement intégré (EDI)
EDI ou Editeur AVANTAGES INCONVENIENTS

Visual studio Gratuit, développement aisé avec un -
code grand nombre de langage et une large
palette d’extensions mise à notre
disposition
Il nous a permis d’éditer les sources de
notre application.
NetBeans Gratuit et open source, développement Auto-complétions incomplète et
rapide des applications, supporte bon manque e coloration syntaxique
nombre de langage de programmation et pour certains langages de
serveurs d’applications programmations tels
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLIX

qu’AngurlarJS, PHP
PHP Storm Développement aisé, affichage des Payant
erreurs a la volé auto-complétions
intelligente du code et dédié en grande
partie au PHP
Sublime text C’est un éditeur de texte générique codé Difficile a modifié, licence
en C++ et Python, disponible sur nécessaire
Windows, Mac et Linux.
Komodo IDE Gratuit, développement aisé avec un Plugins instables

grand nombre de langage
Tableau 11 : Environnement de développement intégré (EDI)

La solution devant être mis sur pied en JavaScript, nous nous pencherons donc sur
l’éditeur Visual studio code pour sa grande panoplie d’extension.
II.3.3. Choix du système de gestion de base de données (SGBD)
Un système de gestion de base de données (SGBD) est un système destiné à stocker et

à partager des informations dans une base de données, en garantissant la qualité, la pérennité
et la confidentialité des informations, tout en cachant la complexité des opérations. Il permet
d’inscrire, de retrouver, de modifier, de trier, de transformer les informations de la base de
données. Il permet également d’effectuer des compte-rendu des informations enregistrées et
comporte des mécanismes pour assurer la cohérence des informations, éviter des pertes
d’informations dues à des pannes, et permettre son utilisation par d’autres logiciels.
En raison de la sa grande adaptabilité, de la rapidité dans le traitement des requêtes

notre choix s’est penché sur le SGBD MongoDB.
II.3.4. Choix de la méthode de gestion de branches (GIT)

Dans le cadre du développement et de l'intégration du microservice de gestion de
documents numériques dans la plateforme académique, nous avons choisi la méthode de
gestion de branches GITFLOW pour faciliter la gestion du code source et l'intégration des
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim L

fonctionnalités développées. Cette méthode nous a permis d'organiser la création, la

validation et la publication des différentes branches de développement tout en garantissant la
stabilité et la qualité du code.
Le diagramme illustratif suivant représente le flux de travail de GITFLOW que nous

avons suivi tout au long du projet :
Figure 12 : Git Flow
Grâce à cette méthode de gestion de branches, nous avons pu travailler efficacement

en équipe tout en maintenant une version stable de la plateforme académique. Les différentes
branches de développement ont été gérées de manière méthodique, facilitant la résolution des
conflits et la mise en production des nouvelles fonctionnalités.
II.4. Expérimentation dans le cadre d’une structure universitaire :

IUEs INSAM
IUES INSAM de Bafoussam est un institut universitaire. Il représente un réel champ
d’expérimentation pour notre système, en flexibilité et les exigences du personnel constituent
autant de besoins à satisfaire.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim LI

II.4.1. Interface de connexion

L’interface de connexion de notre système requiert l’authentification de l’utilisateur à
travers son email (associer à son matricule) et son mot de passe.
Figure 13 : Interface de connexion
II.4.2. la page d’accueil (vue d’ensemble)
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim LII

Après authentification, la page d’accueil s’affiche, l’utilisateur a une liste de tous les
microservices disponibles de la plateforme, il peut donc avoir accès à notre service de gestion
des document en cliquant sur l’une des card suivante : Rapport de stage, Support de cours,
Epreuve d’examen.
Figure 14 : Interface vue d’ensemble (Accueil)
II.4.3. La page libraires
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim LIII

Sur cette page l’utilisateur a accès au document numérique avec un menu qui le
permet de naviguer entre les catégorie et un filtre qui le perme de rechercher et de défini des
règles de trie de document tel que : l’année et le niveau.
Figure 15 : la page libraires
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim LIV

II.4.4. la page profil utilisateur

Sur cette page, l’étudiant aura un espace personnel ou il pourra voir c’est réalisations
et ces activités académique sur la plateforme.
Figure 16 : la page profil utilisateur
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim LV

CONCLUSION GENERALE
Après plusieurs mois de travail, ce rapport de stage de licence présente les résultats de
développement et d'intégration d'un microservice de gestion de documents numériques dans
une plateforme de gestion des activités académiques. Bien que le projet ne soit pas encore
entièrement achevé et que quelques fonctionnalités restent à implémenter, la mission a été
accomplie avec succès à hauteur de 80%. Le microservice fonctionnel a été conçu et
développé avec une architecture logicielle répondant aux besoins de la plateforme avec une
attention particulière portée à la scalabilité, la sécurité et la performance. Ce stage m’a permis
d'améliorer mes compétences en développement logiciel, en gestion de projet et en travail en
équipe, tout en comprenant l'importance de la gestion de documents numériques pour les
institutions académiques. Les compétences et l'expérience acquises au cours de ce stage seront
précieuses pour des projets futurs et dans le monde professionnel. En dépit de quelques défis
rencontrés, ce stage a été une expérience enrichissante et formatrice, et je suis
reconnaissant(e) d'avoir eu cette opportunité.
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLV

REFERENCES
[1] Support de cours UML : M. KODJO

[2] Support de cours introduction au génie logiciel : M. TEJIOGNI
[3] StackOverflow : il s’agit de l’un des meilleurs forums pour les développeurs informatique. En
effet, au cours du développement il y’a eu certains bugs et bon nombre de solutions ont été
retrouvés sur ce forum.
[4] Tutoriel sur le site OpenClassrooms (Passez au FullStack avec Node.js, Express et MongoDB)
[5] Documentation officiel reactJS
[6] Documentation officiel mongoDB
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLVI

TABLE DE MATIERES
EPIGRAPHIE.............................................................................................................................ii
DEDICACE...............................................................................................................................iii
REMERCIEMENTS..................................................................................................................iv
SOMMAIRE...............................................................................................................................v
AVANT PROPOS.....................................................................................................................vi
RESUME..................................................................................................................................vii
ABSTRACT............................................................................................................................viii
LISTE DES ABREVIATIONS.................................................................................................ix
LISTE DES FIGURES...............................................................................................................x
LISTE DES TABLEAUX.........................................................................................................xi
INTRODUCTION GENERALE................................................................................................1
PARTIE I : PRESENTATION DE L’ENTREPRISE, DEROULEMENT DU STAGE ET
GENERALITES.........................................................................................................................3
CHAPITRE I : PRESENTATION DE L’ENTREPRISE, DEROULEMENT DU STAGE
ET GENERALITES................................................................................................................4
I. PRESENTATION DE L’ENTREPRISE.........................................................................4
I.1. Historique.................................................................................................................4
I.2. Plan de localisation...................................................................................................5
I.3. Organigramme..........................................................................................................6
II. DEROULEMENT DU STAGE.....................................................................................6
II.1. Accueil....................................................................................................................7
II.2. Activités du stagiaire...............................................................................................7
CHAPITRE II : GENERALITES SUR LA GESTION DE DOCUMENTS NUMERIQUE
DANS LES UNIVERSITES...................................................................................................9
I. DEFINITION...................................................................................................................9
II. POURQUOI NUMERISER LES DOCUMENTS D'UNE UNIVERSITE ?.................9
III. SECURITE ET CONFIDENTIALITE.......................................................................10
IV. CONCLUSION...........................................................................................................10
PARTIE II : CAHIER DE CHARGES, ANALYSE, CONCEPTION ET
IMPLEMENTATION...............................................................................................................11
CHAPITRE III : CAHIER DES CHARGES ET ANALYSE DE L’EXISTANT................12
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLVII

I. PRESENTATION DU PROJET...............................................................................12
I.2. Etat De L’existant...................................................................................................12
I.3. Limites de l’existant...............................................................................................12
I.4. Proposition De Solution..........................................................................................12
I.5. Les besoins ou fonctionnalités attendues................................................................13
I.51. Besoins fonctionnels.........................................................................................13
I.5.2. Besoins non fonctionnels.................................................................................13
I.6. Population cible......................................................................................................14
I.7. Périmètre du projet.................................................................................................14
I.8. Définition des parties prenantes du projet..............................................................14
I.9. Moyens de communication.....................................................................................15
I.10. Les livrables liés au projet....................................................................................15
I.11. Analyse fonctionnelle externe..............................................................................16
I.11.1. Bêtes à cornes................................................................................................16
I.11.2. Diagramme pieuvre.......................................................................................17
II.12. Planification du projet.........................................................................................18
II.12.1. Organigramme des tâches............................................................................18
II.12.2. Réseau ou méthode PERT............................................................................18
II.12.3. Diagramme de GANTT................................................................................19
II.13. Estimation du coût du projet...............................................................................20
II.13.1. Ressources utilisées......................................................................................20
II.13.2. Estimation de la charge de travail................................................................21
II.13.3. Bilan.............................................................................................................23
CHAPITRE IV : CONCEPTION ET IMPLEMENTATION...............................................24
I. CONCEPTION DE LA SOLUTION............................................................................24
I.1. Présentation d’UML...............................................................................................24
I.2. Modélisation avec UML.........................................................................................25
I.2.1. Diagramme de cas d’utilisation.......................................................................25
 L'étudiant accède à l'interface de gestion de rapports de stage...........................28
 Le système affiche une liste des rapports de stage ajoutés par l'étudiant...........28
 L'étudiant sélectionne le rapport de stage qu'il souhaite modifier......................28
 Le système permet à l'étudiant de modifier le rapport de stage sélectionné et
enregistre les modifications......................................................................................28
 Le système envoie une notification au tuteur de stage et à l'enseignant concernés
indiquant qu'une nouvelle version du rapport de stage est disponible......................28
I.2.2. Diagramme de séquence..................................................................................28
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLVIII

I.2.3. Diagramme de classe.......................................................................................29

II. IMPLEMENTATION DE LA SOLUTION................................................................31
II.1. Choix du modèle de cycle de vie..........................................................................31
II.2. Choix des patrons de conception (design patterns)...............................................34
II.3 – Propositions Et Perspectives...............................................................................35
II.3.1 – Cadre De Mise En Œuvre : Atouts / Freins..................................................35
II.3.1.1 – ReactJS......................................................................................................36
II.3.1.2 - MongoDB..................................................................................................36
II.3.1.3 – NodeJS......................................................................................................36
II.4 – Outils de développement utilisés.........................................................................37
II.4.1 – Choix du langage de programmation...............................................................37
II.3.2. Choix de l’environnement de développement intégré (EDI).........................38
II.3.3. Choix du système de gestion de base de données (SGBD)............................39
II.3.4. Choix de la méthode de gestion de branches (GIT).......................................40
II.4. Expérimentation dans le cadre d’une structure universitaire : IUEs INSAM.......41
II.4.1. Interface de connexion...................................................................................41
II.4.2. la page d’accueil (vue d’ensemble)................................................................42
II.4.3. La page libraires.............................................................................................43
II.4.4. la page profile utilisateur................................................................................44
CONCLUSION GENERALE..................................................................................................xlv
REFERENCES.......................................................................................................................xlvi
TABLE DE MATIERES.......................................................................................................xlvii
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XLIX

Contactez moi pour avoir plus d’information sur le projet, même le code source
Whatsapp : +237 677417630
Email : [email protected]
Youtube : https://youtube.com/@art-sider
Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim L

Rapport de Stage

Transféré par

Droits d'auteur :

Formats disponibles

Rapport de Stage

Transféré par

Informations du document

Titre original

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

Rapport de Stage

Transféré par

Droits d'auteur :

Formats disponibles

REPUBIQUE DU CAMEROUN REPUBLIC OF CAMEROON

Rédigé et présenté par :

M. TEJIOGNI Marc M. LIONEL MUNKABU

Manager des Systèmes d’Information Chef des opérations bancaire

et Infrastructures (MS2I) Afriland First Bank

ANNEE ACADEMIQUE : 2022-2023

‘La technologie ne remplace pas les

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim II

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim III

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim IV

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim V

Du Diplôme Supérieur des Études Professionnelles (DSEP)

Ce rapport de stage de licence porte sur le développement et l'intégration d'un

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim VI

activités académiques. La mission consistait à concevoir et développer un microservice

This report aims to summarize a bachelor's degree internship that focused on

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim VII

LISTE DES ABREVIATIONS

MOA : Maître d’ouvrage

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim VIII

LISTE DES FIGURES

Figure 1 : Plan de localisation Afriland First Bank....................................................................6

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim IX

Figure 3: Bêtes à cornes............................................................................................................17

LISTE DES TABLEAUX

Tableau 1 : Les parties prenantes du projet..............................................................................14

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim X

Tableau 3 : Organigramme des tâches......................................................................................18

L'essor des technologies de l'information et de la communication a permis aux

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XI

fonctionnement. Dans ce contexte, l'architecture microservices est de plus en plus utilisée

Plus spécifiquement, j'ai travaillé sur le microservice de gestion de documents numériques

 1er Chapitre, présentation de l’entreprise et déroulement du stage : nous ferons une

 2ème Chapitre, généralités : nous présenterons de manière globale en quoi consiste le

 4ème Chapitre, conception et implémentation : ici, nous montrerons ce que l’on a

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XII

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XIII

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XIV

I.2. Plan de localisation

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XV

ville et de se rapprocher de ses clients, notamment les commerçants et les entrepreneurs

Figure 1 : Plan de localisation Afriland First Bank

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XVI

gestionnaire Gestionnaire chef des Secrétaire

Chef service Caissières

Figure 2 : Organigramme Afriland First Bank Bafoussam

II. DEROULEMENT DU STAGE

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XVII

II.2. Activités du stagiaire

Conception du microservice : une fois les besoins identifiés, j'ai conçu le

Développement du microservice : j'ai ensuite développé le microservice en utilisant

Intégration du microservice : une fois le microservice développé, j'ai procédé à son

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XVIII

train de développer. J'ai testé le microservice pour m'assurer qu'il fonctionnait

Documentation et formation : enfin, j'ai rédigé la documentation technique du

Rédigé et présenté par : NJIKAM MOUNPOU Mohamed Salim XIX

CHAPITRE II : GENERALITES SUR LA

Dans cette section, nous allons définir la gestion de documents numériques, en

II. POURQUOI NUMERISER LES DOCUMENTS D'UNE