Vous êtes sur la page 1sur 33

Cycle de Formation des Ingénieurs en Informatique

Rapport de Stage

Conception et développement d’une


application mobile de gestion de
formation

Elaboré Par
Salma MEJRI

En collaboration avec

Année Universitaire : 2022/2023


Table des matières

Introduction générale 1

2
1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Etude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Méthodologie et langage de conception . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1.1 C’est quoi SCRUM . . . . . . . . . . . . . . . . . . . . . . . . 5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1.3 Le processus de SCRUM . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Langage de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Sprint 0 8
2.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
. . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 Spécifications des besoins fonctionnels . . . . . . . . . . . . . . . . . . . 9
2.1.3 Spécifications des besoins non-fonctionnels : . . . . . . . . . . . . . . . . 10
2.2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Diagramme de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1 Équipe et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2 Le backlog du produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Structure et découpage du projet . . . . . . . . . . . . . . . . . . . . . . 15

16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

23
4.1 Environnement de développement : . . . . . . . . . . . . . . . . . . . . . . . . . 24
. . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

ii
4.2 Technologie et . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1 Technologies et langages utilisées : . . . . . . . . . . . . . . . . . . . . . . 26

Conclusion générale 28

Bibliographie 29

iii
Table des figures

1.1 Le processus de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6


1.2 Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . 12


2.2 Diagramme de . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Découpage en sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 OnBoarding Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17


3.2 Sign In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Sign Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6 Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.7 Trainings Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.9 Register Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Logo Visual Studio Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24


4.2 Logo Visual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4 Logo latex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5 Logo Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6 Logo Google . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.7 Logo Figma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.8 Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.9 Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.10 Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

iv
Liste des tableaux

2.1 Notre équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13


2.2 Backlog du . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 Environnement matériel du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 24

v
Introduction générale

L’évolution constante du monde professionnel exige des entreprises une adaptation


continue à de nouveaux défis et opportunités. Dans ce contexte, la formation et le
développement des compétences des employés sont devenus des piliers essentiels pour la
croissance et la réussite des organisations. C’est dans cette optique que s’inscrit notre projet
de stage, réalisé au sein de l’entreprise TeamWill.
TeamWill, entreprise renommée dans son secteur, a compris l’importance stratégique de la

formation continue de son personnel. Toutefois, gérer et coordonner les inscriptions aux forma-
tions, ainsi que le suivi de leur déroulement, représente un défi logistique de taille. C’est dans
cette perspective que s’inscrit notre mission : concevoir et développer une application mobile
dédiée, qui simplifiera et améliorera significativement la gestion des inscriptions aux
formations pour les employés de TeamWill.
Afin de bien présenter notre travail, le présent mémoire présente six parties :

Le premier chapitre , intitulé « Etude Preliminaire », est consacré à la présentation du


projet ainsi qu’à l’étude des applications existantes en mentionnant leurs avantages et leurs
inconvénients. Après, nous présenterons la solution à proposer tout en répondant aux besoins
dégagés par cette étude.
Le deuxième chapitre vise à déterminer les besoins fonctionnels et non fonctionnels de notre
application, le pattern et le style architectural et nous finissons par présenter les différents cas
d’utilisation.
Le troisième, le quatrième et le cinquième chapitre contenant, chacun d’eux, le
dérou- lement des différents incréments (sprints) en présentant leurs conception et leurs
réalisations avec quelques interfaces.
Un chapitre de clôture portera sur l’environnement de travail ainsi que les outlis
technolo- giques utilisés tout au long de notre projet.
Ce manuscrit s’achèvera par une conclusion générale afin d’exposer les objectifs atteints et
proposer les perspectives d’amélioration possibles.

1
CHaPItre 1

ETUDE PRELIMInaIRE

Plan
1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Etude et critique de l’existant . . . . . . . . . . . . . . . . . . . . . 3

3 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4 Méthodologie et langage de conception . . . . . . . . . . . . . . . . 5


Chapitre 1. Etude Preliminaire

Introduction
Ce chapitre s’intitule ‘Etude de projet’ dans lequel nous abordons en premier temps une
analyse de l’étude de l’existant en s’appuyant sur les points forts et faibles pour proposer une
solution afin d’atténuer les problèmes existants. Finalement, nous introduisons le choix de la
méthodologie du travail et le langage de conception choisi.

1.1 Problématique
Au cœur de mon projet de stage réside une question cruciale : comment faciliter et amélio-
rer le processus d’inscription aux formations, tout en permettant aux employés de TeamWill
d’avoir une visibilité claire sur les formations à venir ? Cette problématique découle de la réa-
lité qu’au sein de toute entreprise axée sur la croissance et l’innovation, la formation continue
est un impératif incontournable. Cependant, la gestion des inscriptions aux formations peut
rapidement devenir complexe et chronophage, entravant ainsi la participation des employés et
la performance globale de l’entreprise. De plus, le manque de transparence quant aux forma-
tions à venir limite la capacité des employés à planifier leur développement professionnel. Il
devient alors essentiel de mettre en place une solution qui réponde à ces défis tout en offrant
une expérience utilisateur optimale.

1.2 Etude et critique de l’existant


Avant d’entamer le développement de notre application mobile destinée à faciliter la ges-
tion des inscriptions aux formations pour les employés de TeamWill, nous avons entrepris une
analyse approfondie de l’existant. Actuellement, TeamWill utilise principalement des
méthodes manuelles et des systèmes papier pour gérer les inscriptions aux formations. Ce
processus s’avère chronophage et sujet à des erreurs humaines, en plus de rendre difficile
l’accès des employés à des informations à jour sur les formations proposées.
La principale méthode en place consiste en des formulaires papier ou des e-mails envoyés
aux responsables des formations pour les inscriptions. Ces formulaires doivent ensuite être
traités manuellement, ce qui engendre des retards dans la confirmation des inscriptions et
augmente le risque d’erreurs dans la saisie des données. De plus, la visibilité des employés sur
les formations à venir est limitée, car ces informations ne sont pas toujours centralisées et
accessibles en temps réel.

3
Chapitre 1. Etude Preliminaire

En outre, l’absence d’une plateforme numérique dédiée pour la gestion des formations ne
permet pas d’exploiter pleinement le potentiel offert par les technologies actuelles pour auto-
matiser les processus, faciliter la communication, et offrir une expérience utilisateur optimale.
Cette analyse met en lumière les lacunes et les inefficacités du système actuel, démontrant
ainsi la nécessité pressante de notre projet d’application mobile. Notre solution vise à rationa-
liser le processus d’inscription, à éliminer les erreurs potentielles, à centraliser les informations
sur les formations, et à offrir une expérience utilisateur fluide et conviviale. Elle répond ainsi
de manière directe aux défis identifiés dans l’étude de l’existant, en contribuant à la
modernisation
des processus de formation au sein de TeamWill.

1.3 Solution proposée


Face aux lacunes identifiées dans l’étude de l’existant, notre solution consiste en la concep-
tion et le développement d’une application mobile dédiée, spécialement adaptée aux besoins
des employés de TeamWill en matière d’inscription aux formations et d’accès à des
informations actualisées sur les formations à venir.
L’application mobile sera conçue pour offrir une interface utilisateur intuitive et conviviale,
permettant aux employés de consulter rapidement les formations disponibles, de s’inscrire en
quelques clics, et de recevoir des confirmations instantanées. De plus, un système de
notification intégré alertera les employés des formations à venir, garantissant ainsi une
visibilité accrue sur les opportunités de développement professionnel. Pour une gestion plus
efficace, l’application permettra également aux gestionnaires de formations de superviser les
inscriptions, d’ajouter de nouvelles sessions de formation, et de générer des rapports sur la
participation.
La solution proposée impliquera également une intégration étroite avec les systèmes
internes de TeamWill pour garantir la cohérence des données et la sécurité de l’information.
Cela per- mettra une communication fluide entre l’application mobile et les autres outils
utilisés au sein de l’entreprise.
En outre, notre solution inclura un volet d’analyse des données pour aider TeamWill à
suivre la participation aux formations, à évaluer leur efficacité, et à ajuster leur offre de forma-
tion en conséquence. De plus, l’application sera extensible, permettant d’ajouter de nouvelles
fonctionnalités à mesure que les besoins de l’entreprise évoluent.

4
Chapitre 1. Etude Preliminaire

1.4 Méthodologie et langage de conception


Pour obtenir un projet bien organisé et structuré, nous allons adopter une des méthodes
agiles : la méthode SCRUM, qui permet de réaliser un pilotage du travail plus sécurisé pour
faciliter la tâche de conception ainsi que celle de développement.

1.4.1 Méthodologie

Depuis longtemps, les méthodes de développement des projets informatiques étaient basées
sur la planification et le découpage extensifs du projet en lots séquentiels.Néanmoins, le
marché technologique devient de plus en plus concurrentiel et les clients de plus en plus
exigeants. C’est pour cela à la fin des années 90 les méthodes classiques étaient remplacées par
les méthodes agiles ce qui permettent l’implication et la participation active du client tout au
long du projet. En effet, cette approche a été principalement créée pour les projets
informatiques. Mais, elle a pris une grande place même dans des entreprises d’autres domaines
grâce à sa gestion réactive, incrémentale et itérative.
1.4.1.1 C’est quoi SCRUM ?

Scrum est la méthode Agile la plus utilisée de nos jours. Elle est créée en 2002 par Ken
Schwaber et Mike Beedle. Son objectif est d’améliorer la productivité des équipes. Cette ap-
proche est caractérisée par une répartition des tâches à faire, elle s’appuie sur le découpage
d’un projet en « boites de temps » appelées sprints. Ces derniers peuvent durer entre quelques
heures et un mois, chaque sprint se termine par une démonstration du résultat achevé : on
ne peut pas passer d’une tache à une autre qu’après l’analyse attentive de sprint achevé afin
d’améliorer les pratiques du développement et surmonter les lacunes provoquées.
1.4.1.2 Les rôles

La méthode SCRUM présente trois rôles principaux :

• Product Owner : (propriétaire du produit) : Personne qui porte la vision du produit à


réaliser, ayant la responsabilité de maintenir à jour le product backlog, définie la prio-
rité des fonctionnalités et prend les décisions importantes concernant l’orientation du
projet.[?]

• Scrum Master : (chef de mêlée) : Membre de l’équipe dont l’objectif phare est de faciliter
les interactions entre les membres de Scrum, il joue le rôle d’un gardien de la bonne
application en éliminant tous types d’obstacles qui peuvent empêcher l’équipe d’atteindre
les objectifs fixés pour son travail.

5
Chapitre 1. Etude Preliminaire

• Development Team : (équipe de développement) : ce sont les personnes chargées de


trans- former les besoins du propriétaire du produit en des fonctionnalités utilisables.
Cette équipe peut être composée de 2 à 10 membres

1.4.1.3 Le processus de SCRUM

Un projet Scrum inclue un ensemble de réunions régulières et limitées dans le temps :

• Planification du Sprint (Sprint Planning)


Au cours de cette réunion, l’équipe de développement choisit les tâches prioritaires du
carnet du produit qu’elle est capable de réaliser au cours du sprint (en accord avec le
gestionnaire du produit).

• Revue de Sprint (Sprint Review)


À la fin du sprint, l’équipe de développement présentera les fonctionnalités complètes
et recueillera les commentaires des chefs de produit et des utilisateurs finaux. Une fois
la révision terminée, un nouveau cycle d’itération commence, qui redémarre la boucle :
planification, développement et révision

• Rétrospective de Sprint (Sprint Retrospective)


La rétrospective entre la revue du sprint terminé et la planification du prochain Sprint
est une opportunité d’amélioration au niveau de la productivité, la qualité, l’efficacité, les
conditions de travail. . . dans le prochain sprint.

• Mêlée quotidienne (Daily Scrum)


Il s’agit d’une réunion de synchronisation de l’équipe de développement pour ajuster la
progression du travail des membres de l’équipe. La réunion quotidienne dure jusqu’à 15
minutes.
On peut résumer tous dans la figure suivante qui illustre le processus de Scrum :

FIgURE 1.1 : Le processus de Scrum

6
Chapitre 1. Etude Preliminaire

1.4.2 Langage de conception

Pour la spécification des besoins, nous allons utiliser UML (Unified Modeling Language).
C’est un langage désigné pour modéliser graphiquement les données et les traitements à base
de pictogrammes. De plus, grâce à sa notation graphique, il permet d’exprimer visuellement
une solution objet, ce qui facilite la comparaison et l’évaluation des solutions.

FIgURE 1.2 : Logo UML

Conclusion
Au cours de ce chapitre, nous avons introduit le contexte et la problématique de notre projet
suivi d’une étude critique de l’existant. Cette dernière nous a permis de présenter une solution
qui va remédier aux lacunes des applications actuelles en présentant finalement la
méthodologie de travail ainsi que le langage de modélisation. Le chapitre suivant va
s’intéresser au sprint 0 de ce projet.

7
CHaPItre 2

SPRInT 0

Plan
1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . 12

3 Diagramme de . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Pilotage du projet avec SCRUM . . . . . . . . . . . . . . . . . . . . 13


Chapitre 2. Sprint 0

Introduction
Ce chapitre vise à appliquer la méthode Scrum qui sert à organiser le projet, définir ses
fonctionnalités et améliorer la performance de l’application en vue. En premier temps, nous
allons commencer par « Le sprint zéro » qui est la première étape placée au début de chaque
nouveau projet. Cette étape consiste à mettre les bonnes bases, aider l’équipe de se former
et d’apprendre le principe de travail collaboratif. Par la suite, nous spécifions les différents
acteurs, les besoins fonctionnels et non-fonctionnels, le pilotage des projets avec Scrum ainsi
que la planification d’autres sprints.

2.1 Spécification des besoins


2.1.1 Identification des acteurs

Cette application présente 2 acteurs principaux :

• Admin
C’est un utilisateur inscrit, Un administrateur peut gérer la partie back office de l’ap-
plication, gérer les formations ,gérer les évènements, Consulter le tableau de bord et les
réclamations etc . . .

• Employés
C’est un utilisateur inscrit. Un employé peut gérer les informations liées à son compte,
consulter les événements ou les formations etc . . ..

2.1.2 Spécifications des besoins fonctionnels

Admin :

• Authentification
L’admin peut s’authentifier.

• Gestion des formations


L’admin peut approuver la demande d’adhésion d’une formation sur la liste .
L’admin peut approuver la demande de participation d’un employé au sein d’une
formation .

9
Chapitre 2. Sprint 0

• Gérer les catégories


l’admin peut créer des catégories de formation
l’admin peut modifier les catégories de formation
l’admin peut supprimer les catégories de formation

• Gestion des réclamations


l’admin peut traiter une réclamation ou la supprimer

• vérification des comptes


l’admin peut vérifier les comptes des formateurs

Employé :

• S’inscrire
l’employé doit créer un compte

• Authentification
L’Employé peut se connecter à travers : Email(Email TeamWill)/Mot de passe.

• Gestion de profil
l’Employé peut modifier ses informations personnelles.

• Gestion des formations


L’Employé peut consulter la liste des formations disponibles selon leur catégorie.
L’Employé peut demander la participation au sein d’une formation .

• Evaluation
Les employés peuvent évaluer les formations auxquelles ils ont participé.

• Gestion des réclamations


Les employés peuvent envoyer des réclamations.

2.1.3 Spécifications des besoins non-fonctionnels :

Ces besoins fondamentaux sont des contraintes techniques que notre application doit les
satisfaire :

• La rapidité
le temps d’exécution des différents traitements de l’application doit être aussi proche que
possible du temps réel.

• La performance
Le temps de réponse de l’application doit être le plus court possible.

10
Chapitre 2. Sprint 0

• La sécurité
Nous devons garantir les données.

• La fiabilité
Notre application doit toujours fonctionner sans erreur.

• L’extensibilité
Le système doit garantir la sécurité, la confidentialité des accès, la gestion des utilisateurs
et la traçabilité.

• La maintenance
Pour pouvoir être réutilisé et modifié, le code doit être facile à comprendre et modulaire

• L’ergonomie et la convivialité
L’application doit avoir une interface facile à lire et à comprendre

11
Chapitre 2. Sprint 0

2.2 Diagramme de cas d’utilisation global

FIgURE 2.1 : Diagramme de cas d’utilisation global

2.3 Diagramme de classe

FIgURE 2.2 : Diagramme de classe l

12
Chapitre 2. Sprint 0

2.4 Pilotage du projet avec SCRUM


2.4.1 Équipe et rôles

L’équipe d’un projet se basant sur Scrum assemble différents membres remplissant des rôles :

• Le Product Owner : Celui qui possède le produit et le responsable principal du projet.

• Le Scrum Master : Son rôle est de s’assurer de la coopération des membres et les
protéger des perturbations extérieures.

• Developement Team : C’est l’équipe responsable de la réalisation du meilleur produit.

Le tableau ci-dessus présente notre équipe Scrum :

Product Owner TeamWill Consulting


Scrum Master Chef de projet
Developpement Team Salma MEJRI

TablEaU 2.1 : Notre équipe SCRUM

2.4.2 Le backlog du produit

13
Chapitre 2. Sprint 0

ID Fonctionnalité ID User story Priorité


1 S’inscrire 1.1 En tant qu’employés, je veux m’inscire . M
2 S’authentifier 2.1 En tant qu’administrateur,ou employé, je M
dois m’authentifier.
3 Gestion des catégories 3.1 En tant qu’administrateur, je veux ajouter M
des catégories
3.2 En tant qu’ administrateur, je veux modifier W
des catégories
3.3 En tant qu’ administrateur, je veux suppri- W
mer des catégories
3.4 En tant que employé, je veux consulter des M
catégories
4 Gestion de profil 4.1 En tant qu’employé, je veux modifier les in- M
formations personnels de mon profil
5 5.1 En tant qu’administrateur, je veux consulter M
Gestion des réclamation
les réclamations.
5.2 En tant qu’employé , je veux envoyer des ré- M
clamations.
6 6.1 En tant qu’administrateur, je veux ajouter M
des formations
Gestion des formations
6.2 En tant qu’ administrateur, je veux modifier W
des formations
6.3 En tant qu’ administrateur, je veux suppri- W
mer des formations
6.4 En tant qu’empoyé ,je veux consulter les for- C
mations et s’enregistrer dans une formations.
7 Vérification des comptes 7.1 En tant qu’administrateur,je veux verifier les C
comptes des employés .
8 Evaluation 8.1 En tant qu’employé je veux évaluer une for- M
mation .

TablEaU 2.2 : Backlog du produit

14
Chapitre 2. Sprint 0

2.4.3 Structure et découpage du projet

Dans ce qui suit, nous présentons le découpage de notre projet en des incréments
regroupant des fonctionnalités et qui sont nommés « Sprints ». Un Sprint dure d’une à
quatre semaines. Il est caractérisé par une publication sur la production de différentes tâches
effectuées. Nous allons détailler les différentes Sprints qui vont aboutir au développement de
notre projet dans la figure ci-dessous.

FIgURE 2.3 : Découpage en sprints

Conclusion
Dans ce chapitre, nous avons déterminé les spécifications et les exigences de notre applica-
tion.Ainsi, nous avons identifié les rôles de notre équipe scrum suivi du backlog du produit qui
a été découpé en des sprints. Dans ce qui suit, nous allons entamer le premier incrément de
notre application en détaillant les différentes fonctionnalités qui le décrivent.

15
CHaPItre 3

RéaLIsaTIon

Plan
1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapitre 3. Réalisation

Introduction
Cette activité est la dernière phase du cycle de développement du sprint. Nous allons ap-
pliquer les pratiques des tests qui permettent de vérifier les résultats obtenus lors de la phase
de développement afin d’assurer une version de bonne qualité. Dans ce qui suit, nous allons
illustrer la phase de développement par des captures d’écrans des fonctionnalités développées.

3.1 Test

FIgURE 3.1 : OnBoarding Screen

17
Chapitre 3. Réalisation

FIgURE 3.2 : Sign In Screen

FIgURE 3.3 : Sign Up Screen

18
Chapitre 3. Réalisation

FIgURE 3.4 : Menu Screen

FIgURE 3.5 : Scroll View

19
Chapitre 3. Réalisation

FIgURE 3.6 : Categories Screen

FIgURE 3.7 : Trainings Screen

20
Chapitre 3. Réalisation

FIgURE 3.8 : Details Screen

FIgURE 3.9 : Register Screen

21
Chapitre 3. Réalisation

FIgURE 3.10 : Account Screen

22
CHaPItre 4

Phase de cLôTURE

Plan
1 Environnement de développement : . . . . . . . . . . . . . . . . . . . 24

2 Technologie et . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Chapitre 4. Phase de clôture

Introduction
Dans le sixième et l’ultime chapitre de notre rapport, nous allons nous intéresser à la phase
de clôture qui est une phase essentielle dans laquelle nous présentons l’environnement matériel
et les logiciels utilisés lors de la réalisation de ce projet.

4.1 Environnement de développement :


Cette section sera consacrée pour présenter l’environnement matériel ainsi l’environnement
logiciel que nous avons utilisé pour mettre en œuvre notre projet.

4.1.1 Environnement matériel :

Le tableau ci-dessous présente les caractéristiques techniques des machines que nous avons
utilisés :

Ordiateur portable 1
Processeur core i7
Ram 20Go
Disque Dur 512Go SSD
Système d’exploitation Windows 10 professionnel

TablEaU 4.1 : Environnement matériel du projet

4.1.2 Environnement logiciel :

Dans cette section, nous présentons les différentes technologies utilisées pour l’élaboration
de notre projet :

FIgURE 4.1 : Logo Visual Studio Code

Visual Studio Code est un éditeur de code open-source développé par Microsoft supportant
un très grand nombre de langages grâce à des extensions. Il supporte l’autocomplétion, la
coloration syntaxique, le débogage, et les commandes git.

24
Chapitre 4. Phase de clôture

FIgURE 4.2 : Logo Visual Paradigm

Visual Paradigm est un logiciel de création de diagrammes dans le cadre d’une programma-
tion. Tout en un, il possède plusieurs options permettant une large possibilité de modélisation
en UML .
Il est basé sur le cloud et nous permet de stocker notre conception en ligne.

FIgURE 4.3 : Logo overleaf

OverLeaf est un éditeur du langage LaTeX basé sur le cloud.Cet éditeur nous a permis de
partager le rapport de notre projet et de donner un accès choisi, lire seulement ou modifier avec
le propriétaire du projet.

FIgURE 4.4 : Logo latex

Latex est un langage de description gratuit, libre et facile à utiliser.Latex nous permet de
nous concentrer sur le contenu du document .Tandis que tout le reste est généré automatique-
ment.

25
Chapitre 4. Phase de clôture

FIgURE 4.5 : Logo Github

GitHub est une plateforme en ligne qui offre des services d’hébergement et de gestion de
code source, ainsi que des outils de collaboration pour les développeurs de logiciels.[?]

FIgURE 4.6 : Logo Google Drive

Google Drive est un espace de stockage et de partage de fichiers sur le cloud. Nous l’avons
utilisé pour stocker les versions de notre projet.

4.2 Technologie et logiciels


4.2.1 Technologies et langages utilisées :

FIgURE 4.7 : Logo Figma

Figma est un éditeur de graphiques vectoriels et un outil de prototypage. Il est principa-


lement basé sur le web, avec des fonctionnalités hors ligne supplémentaires activées par des
applications de bureau pour macOS et Windows.

26
Chapitre 4. Phase de clôture

FIgURE 4.8 : Logo Dart

Dart est un langage de programmation optimisé pour les applications sur plusieurs plate-
formes. Il est développé par Google et est utilisé pour créer des applications mobiles, de
bureau, de serveur et web.

FIgURE 4.9 : Logo Flutter

Flutter est un kit de développement logiciel d’interface utilisateur open-source créé par
Google. Il est utilisé pour développer des applications pour Android, iOS, Linux, Mac, Windows,
Google Fuchsia et le web à partir d’une seule base de code.

FIgURE 4.10 : Logo Strapi

Strapi est un système de gestion de contenu (CMS) open source qui permet de créer, de
gérer et de fournir des contenus numériques de manière flexible et personnalisée.

Conclusion :
Dans ce chapitre, nous avons mentionné les différentes technologies et logiciels avec
lesquels nous avons pu développer notre application. Notre choix est principalement axé sur les
nouvelles tendances de l’ingénierie actuelle et du développement . Nous disposons
actuellement d’une version de l’application qui répond aux exigences et aux besoins cités au
début du projet.

27
Conclusion générale

La réalisation de ce projet de stage visant à concevoir et développer une application mobile


dédiée aux employés de TeamWill pour simplifier la gestion des inscriptions aux formations
et améliorer la visibilité des opportunités de développement professionnel a été une entreprise
passionnante et fructueuse. Au fil de ces pages, nous avons exploré chaque étape du processus,
de l’étude de l’existant à la conception, du développement à la mise en service. Ce projet nous
a offert des opportunités d’apprentissage inestimables, nous permettant de mettre en pratique
nos compétences et nos connaissances dans un contexte professionnel concret.
L’application que nous avons créée repose sur des principes de simplicité, d’intuitivité et
d’efficacité, et elle représente une réponse directe aux besoins de TeamWill en matière de for-
mation continue. Elle contribuera à rationaliser les processus internes, à réduire les erreurs
administratives et à offrir aux employés une plateforme fluide pour accéder aux formations.
Au-delà de ces avantages pratiques, l’application incarne également notre engagement envers
l’entreprise TeamWill, en participant à sa croissance et en favorisant le développement des
compétences de ses employés.
Nous sommes convaincus que cette application mobile a le potentiel de devenir un atout
précieux pour TeamWill, améliorant la formation et le développement professionnel au sein
de l’entreprise. Cependant, notre travail ne s’arrête pas ici. Nous envisageons de continuer à
collaborer avec TeamWill pour surveiller les retours des utilisateurs, apporter des améliorations
et élargir les fonctionnalités de l’application.
Ce projet de stage a été une expérience enrichissante qui nous a permis d’appliquer nos
compétences techniques et notre compréhension des besoins des entreprises dans un contexte
réel. Nous tenons à remercier chaleureusement l’équipe de TeamWill pour sa collaboration
précieuse et son soutien tout au long du projet. En fin de compte, cette expérience renforce
notre conviction que la technologie peut jouer un rôle clé dans l’amélioration des processus
opérationnels et dans la promotion du développement professionnel au sein des organisations.
Ce rapport reflète notre engagement envers l’excellence, et nous espérons qu’il servira de
ressource utile pour les futures initiatives de développement au sein de TeamWill.

28

Vous aimerez peut-être aussi