République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur et de la Recherche

Scientifique
Université des Sciences et de la Technologie Houari Boumediene
Faculté d’Informatique
Département d’Informatique
Mémoire de Licence
Spécialité :
Informatique Générale

Thème :
Management visuel dynamique de l’affectation
personnel usine

Présenté par : Encadré par :

Meliouh Wissam Mr. Tarik Zakaria Benmerar :
Khene Soraya USTHB
Binome numéro : Mme. Hind Baslimane :
ACAD_032 MINIROS

Soutenu le 05/06/2023 , Devant le jury composé de :

Mr. BENKAOUHA HAROUN : - Président

Mme. BENATIA IMENE : - Membre

Promotion : 2022/2023
 REMERCIEMENT

Avant tout, nous remercions dieu ALLAH, le tout-puissant, de nous avoir donné de la
santé, de la volonté, du savoir.

Nous tenons à remercier toutes les personnes qui ont contribué au succès de notre stage
et qui nous ont aidé lors de la rédaction de ce rapport.
Nous adressons également nos sincères remerciements à Mme. Hind Baslimane notre proma-
trice au niveau de « MINIROS », pour son suivi, ses orientations, ses connaissances et les
détails fournis durant toutes les réunions de ce projet.

Nos sincères remerciements aux membres du jury qui ont accepté d’assister à notre
soutenance et d’évaluer notre travail.
 DÉDICACE

Je dédie ce mémoire à :

Mes chers parents, qui ont consacré leur vie pour que je puisse poursuivre mes études et
qui m’ont apporté un soutien constant. Leur amour, leurs encouragements et leurs sacrifices
ont été essentiels dans mon parcours académique.

J’adresse également ma dédicace à mes sœurs, qui ont toujours été là pour m’aider
et m’encourager. Leur soutien inconditionnel et leur présence précieuse ont été une source
de motivation et de force tout au long de cette période. Ma chère amie Amina, qu’elle ma
donnée. Sa confiance en moi et ses encouragements ont été une source d’inspiration et de
tout au long de cette expérience.

A mon binôme Soraya, pour son aide tout au long du projet. Nous avons partagé de bons
moments ensemble. Son soutien, sa collaboration et notre travail d’équipe ont grandement
contribué à la réussite de ce mémoire.
Meliouh Wissam
 DÉDICACE

Ce mémoire est dédié avec une profonde gratitude à :

Mes parents, ma mère et mon père, qui ont été une source constante d’inspiration et
de soutien tout au long de ce parcours. Leur soutien moral, spirituel, émotionnel et financier
a été inestimable et a joué un rôle essentiel dans ma réussite.

Je souhaite également exprimer ma reconnaissance envers mes frères Mohammed et

Loukmane, mes amies et mon binôme Wissam pour son aide tout au long du projet. Nous
avons partagé de bons moments ensemble. Son soutien, sa collaboration et son travail
d’équipe ont grandement contribué à la réussite de ce mémoire.
Khene Soraya
 TABLE DES MATIÈRES

Remerciement

Dédicace

Dédicace
Introduction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 Etude de l’existant 2
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Entreprise MINIROS . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Organigramme MINIROS . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.3 Visions MINIROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 Digitalisation à MINIROS . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Service production . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3 Critique de l’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.4 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Analyse et Conception de la solution 11

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Acteurs de système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Explication détaillée du fonctionnement du système . . . . . . . . . . . . . . 12
2.4.1 Responsable de production . . . . . . . . . . . . . . . . . . . . . . . . 12
 2.4.2 Responsable de planification . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Superviseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.4 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.5 Personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.6 Administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Présentation d’UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 14
2.5.2 Modélisation dynamique du système . . . . . . . . . . . . . . . . . . 19
2.5.3 Aspect Statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Réalisation et implémentation 26
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Architecture du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Langages et outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.3 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4 JSX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.5 REACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.6 TailwindCss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.7 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.8 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.9 Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.10 Rest Api . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.11 XAMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.12 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.13 Lucidchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Présentation du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.1 Interface d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4.2 Interface authentification . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.3 Interface administarteur . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.4 Interfaces demande besoin . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.5 Interfaces téléchargement ordre de fabrication . . . . . . . . . . . . . 33
3.4.6 Interface affectation . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.7 Interface affectation service . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.8 Interfaces gestion de la matrice . . . . . . . . . . . . . . . . . . . . . 35
3.4.9 Interface historique d’affectation . . . . . . . . . . . . . . . . . . . . . 37
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Conclusion générale 38
 LISTES DES FIGURES

1.1 Organigrame de l’organisme d’acceuil . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Evolution de l’intégration des solutions de l’informatique au sein de MINIROS 6
1.3 Schéma qui repsésente la situation actuelle . . . . . . . . . . . . . . . . . . . 8
1.4 Affectation personnel usine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Tableau demande besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Diagramme de cas d’utilisation Global . . . . . . . . . . . . . . . . . . . . . 15

2.2 Diagramme de cas d’utilisation de sous système "Gérer comptes" . . . . . . 16
2.3 Diagramme de cas d’utilisation de sous système "Gérer matrice" . . . . . . . 17
2.4 Diagramme de cas d’utilisation de sous système "Gérer affectation" . . . . . 18
2.5 Diagramme de cas d’utilisation de sous système "Gérer besoin" . . . . . . . 19
2.6 Diagramme de séquence "Consulter affectation" . . . . . . . . . . . . . . . . 20
2.7 Diagramme de séquence "Ajouter demande besoin" . . . . . . . . . . . . . . 21
2.8 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Architecture globale de l’application web . . . . . . . . . . . . . . . . . . . . 26

3.2 Page d’acceuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Page d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Message d’erreur "Mot de passe erroné" . . . . . . . . . . . . . . . . . . . . 31
3.5 Page de "Supprimer Utilisateur" . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.6 Formulaire de demande service au responsable planificaiton . . . . . . . . . 32
3.7 Affichage des demandes de service parapport au responsable planification . . 32
3.8 Téléchargement ordre de fabrication . . . . . . . . . . . . . . . . . . . . . . . 33
3.9 Detection de poste d’affectation . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.10 Interface de l’affectation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.11 Affichage des demandes et l’affectation pour les services . . . . . . . . . . . 35
3.12 Affichage affectation service . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.13 Page gestion la matrice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.14 Page de "Consulter Personnel" . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.15 Page d’historique d’affectation . . . . . . . . . . . . . . . . . . . . . . . . . 37
 LISTES DES TABLEAUX

2.1 Acteurs du système et leurs rôles . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Dictionnaire de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
 Introduction générale
L’informatique est devenue indispensable en raison de son efficacité et de son utilité
croissante. Cela se traduit par une multitude d’applications informatiques dans tous les do-
maines, en particulier dans les entreprises. Ces dernières sont contraintes de les intégrer de
manière structurée pour améliorer leur productivité.

La digitalisation est le processus de numérisation des informations, des processus et des

activités. Elle est essentielle pour les entreprises dans l’ère numérique, car elle implique l’in-
tégration des technologies numériques dans tous les aspects de leur activité. Elle permet
l’automatisation des tâches, l’amélioration de la communication et l’accès en temps réel aux
données.

A nos jours, l’organisme d’accueil «MINIROS» planifie tous les jours l’affectation de per-
sonnel aux postes de travail pour atteindre la cadence et les commandes à leur temps et pour
gagner les clients, mais ne dispose pas toujours de solution.
L’objectif de notre projet est d’automatiser l’affectation pour faciliter la prise de décision,
optimiser le temps, garder la traçabilité et simplifier le travail, une application web est conçue
à cet égard.

Afin d’aborder tous ces aspects, nous avons décomposé ce mémoire en trois chapitres es-
sentiels qui se présentent comme suit :

• Le chapitre 01 : Étude de l’existant. Ce chapitre regroupe la présentation de l’orga-

nisme d’accueil, Son organigramme et la problématique par rapport au service.

• Le chapitre 02 : Analyse et Conception de la solution. Ce chapitre concerne la

conception et la modélisation de notre application.

• Le chapitre 03 : Réalisation et Implémentation. Ce chapitre regroupe la présen-

tation des différents outils et technologies utilisés pour la réalisation de l’application et les
interfaces les plus importantes.

1
CHAPITRE 1

ETUDE DE L’EXISTANT

1.1 Introduction
L’analyse de l’existant est une étape importante dans le cycle de vie d’un système, il
s’agit de connaître la situation actuelle de l’organisation pour pouvoir porter les améliorations
demandées. Alors, nous abordons dans ce chapitre une présentation générale de l’organisme
d’accueil, son organigramme, ses visions et son intérêt pour la digitalisation.

1.2 Présentation de l’organisme d’accueil

1.2.1 Entreprise MINIROS
C’est une entreprise de fabrication et de distribution des outillages d’application de
peinture, elle existe depuis 52 ans.
« MINIROS » en quelques chiffres :
• 300 collaborateurs formés, impliqués, motivés et engagés à servir nos clients.
• 4 délégations régionales.
• 240 articles commercialisés.
• Une croissance annuelle de 20%.
• 80 modèles déposés, 2 brevets d’invention, 3 marques commerciales déposées.
• 12,000 contacts et partenaires régulièrement informés, soutenus, conseillés :
– Détaillants
– Entreprises d’application
– Utilisateurs professionnels

2
 – Bureaux d’études spécialisés
• 40 fournisseurs et sous-traitants conventionnés.
• Sponsor officiel du Ministère de la Formation Professionnelle depuis 2008.
Elle a Un système de gestion et une logistique intégrée, utilisant les meilleures techno-
logies, et un système de gestion de la chaine de valeur orienté client, à ce titre :
• Elle synchronise toutes les opérations selon la demande client.
• Elle stabilise l’outil de production et optimise les coûts.
• Elle veille au développement des compétences et de la polyvalence des salariés.

1.2.2 Organigramme MINIROS

L’organigramme de l’entreprise MINIROS est une représentation visuelle de la struc-
ture organisationnelle de l’entreprise, mettant en évidence les différentes directions et les
relations hiérarchique.
Il est organisé de manière verticale, avec des niveaux hiérarchiques clairement définis. En
dessous de la direction générale, nous avons les différentes directions clés. Chaque direction
est représentée par un directeur et est constituée de plusieurs départements, chacun ayant
un responsable.
La direction de l’administration générale comprend un département des ressources humaines
et un autre pour les moyens généraux. La direction de l’usine est composée de plusieurs
services : la production gère la fabrication des produits, la maintenance assure l’entretien
des équipements, l’expédition gère les envois des produits finis, et le contrôle qualité vérifie
la conformité des produits fabriqués, les approvisionnements, méthode et HSE. La direction
commerciale et marketing comprend deux départements distincts : le département commer-
cial et le département marketing. Le département des finances et de la comptabilité gère les
finances et les budgets de l’entreprise. La direction des opérations et du digital comprend la
direction des systèmes d’information(DSI), la direction opérationnelle(DOP) et un bureau
des projets.
Les directeurs de chaque direction sont en relation directe avec le directeur général(PDG).
Ils sont responsables de la gestion et du suivi des opérations dans leur domaine respectif. Les
employés de chaque département rendent compte à leur responsable respectif. La communi-
cation au sein de l’entreprise MINIROS se fait principalement de manière descendante, du
PDG vers les directeurs des directions, puis des directeurs des directions vers les responsables
des départements, et enfin de ces derniers vers les employés.
L’organigramme de MINIROS met en évidence la structure hiérarchique, les directions et les
relations professionnelles au sein de l’entreprise.

3
 Figure 1.1 – Organigrame de l’organisme d’acceuil

1.2.3 Visions MINIROS

Dans les 5 prochaines années, « MINIROS » vise a doubler ses résultats, avec leurs
force qui sera l’accompagnement innovant et moderne des professionnels dans la réalisation
de ses projets à travers les territoires et les pays qu’ils viseront et la reconnaissance de ses

4
clients de la valeur qu’ils leur donnent, de ses dynamique d’innovation et de ses engagement
qualité. Dans le cadre de la digitalisation, faire la transformation digitale : Allant vers un
contrôle automatisé, une optimisation et une intégration digitale, son système informatique
devrait voire une percée.

1.2.4 Digitalisation à MINIROS

Le projet de transformation que mène « MINIROS » depuis 2016, se poursuit natu-
rellement vers la transformation digitale pour être aligné a sa vision allant vers un contrôle
automatisé, une optimisation et une intégration digitale, son système informatique devrait
voir une percée. Aujourd’hui, après le mise en œuvre des process, l’apprentissage et l’applica-
tion de l’agilité, la définition de suivi de leurs kpi "KEY PERFORMANCE INDICATORS",le
métier et la DSI "Direction des Systèmes d’information"sont prêts pour une transition digi-
tale forte qui tient compte de toute les démarches déployées lors du projet de transformation.

Cette approche permettra à « MINIROS » d’optimiser ses performances et d’assurer une

meilleure satisfaction client.

Les dimensions de projet sont :

• RH & Accompagnement IT
– La gestion du changement : gestion de la transition entre ancien et nouveau sys-
tème.
– La restructuration DSI.
– La formation aux nouvelles technologies, bests practices.
• Management IT
– Le SMSI : le Système de Management de la sécurité informatique.
– Le ITSM : le système de management des Services Informatiques.
– Urbanisation & Architecture.
• Business & Opérations
– La GED : la gestion électronique des documents.
– La BI : le Tableau de bord, décisionnel.
– L’ERP : l’intégration des modules de la chaine de valeur et fonctions support.
∗ Le CRM : La gestion de la relation client, avec le GIS.
∗ Le SIRH : Le système d’information RH.
∗ Autres modules fonctionnels.
– L’IOT : Liaison avec les machines et objets connectés : GPS, Traçabilité Produits.

5
Figure 1.2 – Evolution de l’intégration des solutions de l’informatique au sein de MINIROS

1.3 Cadre du projet

Nous devons fournir une description détaillée du service de production de la direction
usine, ainsi qu’une analyse de la situation actuelle qui mettra en évidence les avantages que
nous apporterons. Nous devons également inclure une critique constructive de l’existant.
Enfin, nous devons établir nos objectifs clairement.

1.3.1 Service production

Le service de production est chargé de la fabrication des produits finis : Pinceau et
Rouleau. Il se compose de deux ateliers, qui permettent de transformer les matières premières
en produits finis destinés à la vente selon les demandes clients. Le service est dirigé par deux
responsables :
• Le responsable de production Pinceau.
• Le responsable de production Rouleau.

Ateliers service de production

Les deux ateliers sont équipés de plusieurs postes avec des niveaux de compétence
variés. Ces postes sont regroupés dans des lignes/cellules destinées à certaines catégories de
produits. Chaque ligne/cellule a un superviseur qui la dirige. Certains postes nécessitent des
employés possédant des compétences élevées.

Matrice de compétences
Les responsables de productions pinceaux et rouleaux ont élaboré une matrice de com-
pétences afin de distinguer le personnel en fonction de leurs compétences spécifiques à chaque

6
poste.
Elle répertorie :
• Les membres du personnel des ateliers dans ses lignes.
• Les noms des postes dans ses colonnes.
• Les compétences des employés pour chaque poste à l’intersection des lignes et des
colonnes. Les compétence sont classées en trois niveaux :
1. Compétence"A" : Expert.
2. Compétence"B" : Maîtrise.
3. Compétence"C" : Basique.
À la fin de chaque année, les responsables de productions analysent cette matrice en
attribuant des taux (pourcentages) à chaque personnel afin de pouvoir obtenir un point
de vue sur :
• Les personnels les plus polyvalents
• Leurs capacités dans chaque poste.
Après avoir effectué cette analyse, ils élaboreront plan de formation ainsi qu’une liste
des besoins en recrutement.

1.3.2 Analyse de l’existant

Nous devons fournir une description détaillée de la situation actuelle.

Situation actuelle
Chaque jour, avant midi, Le responsable central de commande de l’entreprise reçoit
les commandes des clients et les transmet au responsable de planification. Les commandes
doivent être livrées dans un délai de 72 heures.
Le comité de planification"responsable de planification, responsable expédition et respon-
sables de productions pinceau et rouleau" s’occupe chaque jour de la planification des ex-
péditions, de la production et des approvisionnements en fonction des besoins du jour, qui
varient en fonction de la demande et des produits demandés.
La planification se fait chaque jour à midi où les responsables de production affectent les
personnels des ateliers aux différents postes de travail en fonction de la commande en cours,
en prenant en compte :
• les compétences des employés et leur disponibilité.
• Les absences : maladies, employés en congé...
• Les ordres de fabrication(work-order).
• Les besoins d’affectation : Les autres services peuvent demander des employés des
ateliers pour une durée donnée, et inversement.

7
Le Responsable de planification utilise le logiciel "TEAMEX" pour traiter la commande et
générer l’ordre de fabrication qui indique les lignes actives pour chaque atelier, le nombre de
produits par ligne et le temps de travail nécessaire pour chaque ligne. permettant ainsi aux
responsables de faire l’affectation du personnel.
L’affectation se fait chaque jour, et est affiché aux salariés pour que chacun connaisse son
affectation du lendemain. Elle varie chaque jour en fonction de l’ordre de fabrication.

Cette affectation peut subir des changement pendant la journée, soit par les respon-
sables de productions, ou par les superviseurs à cause de plusieurs raisons parmi eux :
• Changement de ligne.
• Absense non prévu.
• Cas d’incidence.
Ces changements sont effectué par les superviseurs. En d’autres termes, ils sont res-
ponsables des modifications d’affectation par rapport à chaque cellule/ligne.

Figure 1.3 – Schéma qui repsésente la situation actuelle

1.3.3 Critique de l’analyse

• L’affectation des personnels se fait manuellement dans la salle de planification sur un
tableau qui regroupe les différentes fiches d’affectation. Il y a une fiche d’affectation
pour l’atelier pinceau, une autre pour l’atelier rouleau, et une dernière pour les absents
et les personnes affectées aux services. Les membres du personnel sont représentés

8
 par des aimants sur le tableau. Une fois l’affectation effectuée, les responsables de
productions prennent des photos du tableau de la salle et se déplacent vers les ateliers
pour recopier les informations sur un autre tableau.

Figure 1.4 – Affectation personnel usine

• Les responsables ne disposent pas d’une liste fiable des absences.

• Les responsables perdent leurs temps en consultant la matrice a chaque fois, ce qui les
oblige à se rappeler des compétences de chaque employé pour affecter.
• Lorsqu’un service souhaite demander du personnel, il envoie un e-mail au responsable
de planification. Celui-ci écrit ensuite la demande sur un tableau afin que les respon-
sables de productions puissent en tenir compte lors de l’affectation.

Figure 1.5 – Tableau demande besoin

• Il n’y a pas un historique d’affectation de chaque jours.

9
 • L’acceptation ou le refus des demandes se fait soit par email, soit par téléphone. Le res-
ponsable de planification utilise ses moyens pour informer les services de la disponibilité
du personnel demandé.
• La matrice de compétences est présente dans un fichier Excel. Elle est imprimée et
affichée pour que les responsables et les employés puissent consulter les compétences
requises et disponibles.

1.3.4 Objectifs
Les problèmes identifiés précédemment se résument comme suit :
• Perte de temps : Le processus actuel implique des tâches manuelles et des déplacements
physiques, ce qui entraîne une perte de temps.
• Absence de traçabilité d’affectation : Il n’y a pas de système en place pour suivre et
enregistrer les affectations du personnel, ce qui rend difficile la vérification des infor-
mations et la recherche d’un historique.
• Risque d’erreurs : Les affectations manuelles peuvent conduire à des erreurs humaines.
• Données non organisées : La matrice de compétences et les absences, ne sont pas
centralisées ou organisées de manière efficace, ce qui rend difficile leur utilisation.
L’objectif est de résoudre ces problèmes en développant une application web qui permettra
de :
• Eliminer la perte de temps en centralisant le processus des demandes besoins, en au-
tomatisant l’affectation manuelle et en permettant le travail à distance, ce qui réduira
les déplacements et les tâches manuelles.
• Assurer une traçabilité d’affectation complète en enregistrant toutes les affectations et
en permettant de consulter facilement l’historique.
• Réduire les risques d’erreurs en automatisant les affectations.
• Centraliser et organiser les données en numérisant la matrice de compétences, faire une
liste fiable des absences.

1.4 Conclusion
Ce chapitre a fourni un aperçu de l’organisation, de sa structure d’accueil et de son
domaine d’activité. Il a également contribué à une meilleure compréhension de la problé-
matique. Étant donné l’absence de logiciel adapté à ces problèmes, nous avons entrepris le
développement de notre propre application. Après avoir défini nos objectifs, nous aborderons
le chapitre suivant qui se concentre sur l’étude conceptuelle de notre application.

10
CHAPITRE 2

ANALYSE ET CONCEPTION DE LA SOLUTION

2.1 Introduction
Après une étude approfondie de l’existant, nous aborderons dans ce chapitre la phase
cruciale de modélisation et de conception de notre projet. Nous commencerons par identifier
les besoins, puis expliquerons le fonctionnement de notre système en décrivant les différents
acteurs impliqués. Enfin, nous présenterons les différents diagrammes et modèles UML que
nous avons utilisés pour la conception de notre solution.

2.2 Analyse des besoins

L’analyse des besoins est la première étape du processus de développement de tout
application. Elle précède la récolte des données et la conception du système. Elle permet de
comprendre les besoins des utilisateurs, les objectifs et les contraintes du système .

2.2.1 Besoins fonctionnels

Notre application web doit en général répondre aux fonctionnalités suivantes :
• Automatiser l’affectation des personnels usine.
• Informatiser la matrice des compétences
• Informatiser le processus des demandes besoins de personnel.

2.2.2 Besoins non fonctionnels

Les besoins qui caractérisent notre système sont :
• Une interface simple et cohérente.

11
 • Un accès rapide.
• Mise à jour facile : Codage lisible commenté avec guide technique .
• Des données sécurisées.
• Manipulation sur Pc / tablette / écran tactile / smartphone .
• Le système doit être disponible 24h sur 24h et 7jrs sur 7jrs pour répondre aux besoins
des utilisateurs.

2.3 Acteurs de système

Nous allons présenter les acteurs de notre système avant de passer à sa conception :

Role
Gérer matrice Gérer Affection Gérer besoin Gérer comptes
Acteurs
Responsable de production ✗ ✗ ✗
Resposable de planification ✗ ✗
Service ✗ ✗
Superviseur ✗
Personnel ✗
Administrateur ✗

Table 2.1 – Acteurs du système et leurs rôles

2.4 Explication détaillée du fonctionnement du système

Dans cette partie, nous allons faire une description des fonctionnalités du système et
pour chacun des acteurs nous détaillerons le rôle qu’il joue dans le système.

2.4.1 Responsable de production

Après s’être authentifié, le responsable de production sera en mesure de réaliser les
actions suivantes :
• Gérer matrice : le responsable de production peut soit gérer personnel (archiver/consulter
personnel) ou gérer compétence (ajouter/modifier compétence) ou bien gérer poste
(ajoute/supprimer/consulter poste).
• Gérer Affectation : il peut lancer l’affectation automatique, consulter/supprimer/modifier
l’affectation, consulter l’historique d’affectation et consulter les personnels compétant
pour un poste donné.

12
 • Gérer Besoin : il peut affecter des personnels ( choisir personnel et choisir service ),
afficher demande besoin des services (accepter/refuser demande).

2.4.2 Responsable de planification

Après s’être authentifié, le responsable de planification sera en mesure de réaliser les
actions suivantes :
• Gérer Affectation : Responsable de planification doit charger l’ordre de fabrication
pour l’affectation automatique, valider l’affectation finale, consulter l’affectation et
l’historique d’affectation.
• Gérer Besoin : Il peut soit afficher ses demandes ou bien ceux des services, ajouter
demandes aux services et valider les réponses aux demandes services.

2.4.3 Superviseur
Après s’être authentifié, le superviseur sera en mesure de réaliser les actions suivantes :
• Gérer Affectation : Superviseur peut consulter, modifier l’affectation.

2.4.4 Service
Après s’être authentifié, le service sera en mesure de réaliser les actions suivantes :
• Gérer Affectation : Service peut consulter l’affectation seulement.
• Gérer Besoin : Il peut envoyer demande au responsable de planification, Afficher ses
demandes, afficher demande besoin du reponsable de planification (accepter/refuser
demande).

2.4.5 Personnel
Sans s’être authentifié, le personnel sera en mesure de réaliser les actions suivantes :
• Gérer Affectation : Le personnel peut consulter l’affectation du jours.

2.4.6 Administrateur
Après s’être authentifié, l’administrateur sera en mesure de réaliser les actions sui-
vantes :
• Gérer Comptes : L’administarteur peut ajouter compte, changer mot de passe, afficher
compte, supprimer compte.

13
2.5 Présentation d’UML
UML (Unified Modeling Language) est un langage de modélisation graphique utilisé
pour représenter les systèmes logiciels. Il est constitué de diagrammes qui servent à visualiser
et décrire la structure et le comportement des objets d’un système. UML propose une série
de diagrammes tels que "Cas d’utilisation, diagramme de séquence, diagramme de classe..."

2.5.1 Diagramme de cas d’utilisation

Un diagramme de Cas d’Utilisation montre l’interaction entre le système et les entités
externes au système. Ces entités externes sont désignées comme acteurs. il répond à la
question « Qui fait quoi ? ». Il indique les évènements dans un système et ne décrit pas
comment ces évènements seront implémentés dans le système.
Nous présenterons dans ce qui suit, les fonctionnalités de nos acteurs :

Diagramme de cas d’utilisation global

D’abord, le responsable de production peut gérer matrice, gérer besoin, gérer affecta-
tion. Responsable de planification et service peuvent gérer affectation, gérer besoin. Ensuite ;
le superviseur peut gérer affectation ; l’admin doit gérer comptes. Tout ça nécessite une au-
thentification. À la fin le personnel doit gérer l’affectation sans authentification.

14
Figure 2.1 – Diagramme de cas d’utilisation Global

15
Diagramme de cas d’utilisation de sous système "Gérer comptes"

Figure 2.2 – Diagramme de cas d’utilisation de sous système "Gérer comptes"

Diagramme de cas d’utilisation de sous système "Gérer matrice"

D’abord, le responsable de production peut soit gérer personnel par ajouter person-
nel ou bien consulter personnel. Tous ça nécessite une recherche du personnel. Soit gérer
compétences par ajouter /modifier compétence. Ces actions nécessite une recherche du per-
sonnel et une recherche du poste. Soit gérer postes par ajouter /supprimer /consulter poste.
Cela nécessite une recherche de la partition ainsi qu’une recherche du poste pour les deux
dernières.

16
 Figure 2.3 – Diagramme de cas d’utilisation de sous système "Gérer matrice"

Diagramme de cas d’utilisation de sous système "Gérer affectation"

D’abord on a le personnel et service qui doivent consulter l’affectation ; Superviseur
peut consulter affectation, modifier affectation. Responsable de production peut soit consul-
ter, modifier, supprimer affectation, lancer l’affectation automatique, consulter les personnels
compétents pour les postes et consulter l’historique d’affectation. Responsable de planifi-
cation peut soit consulter affectation, charger l’ordre de fabrication, consulter l’historique
d’affectation et valider l’affectation finale.

17
 Figure 2.4 – Diagramme de cas d’utilisation de sous système "Gérer affectation"

Diagramme de cas d’utilisation de sous système "Gérer besoin"

D’abord, on a le service qui peut ajouter demande au responsable de planification,
afficher ses demandes ou bien afficher les demandes de responsable de planification ; Ensuite
le responsable de production peut afficher les demandes besoins de services ou bien affecter
le personnel, ce qui nécessite de choisir le personnel et choisir le service. À la fin on a le
responsable de planification qui peut ajouter demande aux services, afficher ses demandes,
afficher les demandes des services et valider les réponses aux demandes services.

18
 Figure 2.5 – Diagramme de cas d’utilisation de sous système "Gérer besoin"

2.5.2 Modélisation dynamique du système

Les diagrammes de séquences sont une solution populaire de modélisation dynamique
en langage UML. Ils permettent de décrire COMMENT les éléments du système interagissent
entre eux et avec les acteurs. Ils montrent les interactions entre objets selon un point de vue
temporel.

19
Diagramme de séquence "Consulter affectation"

Figure 2.6 – Diagramme de séquence "Consulter affectation"

20
Diagramme de séquence "Ajouter demande besoin"

Figure 2.7 – Diagramme de séquence "Ajouter demande besoin"

2.5.3 Aspect Statique

Un diagramme de classes dans le langage de modélisation unifié (UML) est un type de
diagramme de structure statique qui décrit la structure d’un système en montrant les classes
du système, leurs attributs, opérations (ou méthodes) et les relations entre les objets.

Dictionnaire de données
Dictionnaire de données est un document qui regroupe toutes les données qu’on aura
conserver dans notre base de données. Pour chaque donnée, il indiquele code mnémonique,

21
la désignation, le type et la taille de la donnée.

Mnémonique Désignation Type Taille

Id_matrice Identifiant de la matrice bigint 20
matricule Matricule de personnel varchar 6
compétence Compétence de personnel dans un poste varchar 2
Id_user Identifiant de l’utilisateur bigint 20
rôle Rôle de l’utilisateur varchar 255
password Mot de passe de l’utilisateur varchar 255
Id_poste Identifiant de poste int 10
nom_partition Nom de la Partition du poste varchar 255
nom_poste Nom de poste varchar 255
capacité_poste Capacité de poste int 11
atelier Type de l’atelier varchar 255
id_service Identifiant de service int 4
nom_servie Nom de service varchar 255
id_besoin Identifiant de demande besoin int 4
info Information de demande varchar 255
typeInfo Type d’information varchar 255
id_user_Emeteur Identifiant d’émetteur de demande varchar 255
id_user_recepteur Identifiant du récepteur de demande varchar 255
durée Durée de besoin de personnel int 11
heure Heure du besoin time /
date Date de demande date /
validation Validation de demande tinyInt 1
confirmation Confirmation de la demande tinyInt 1
typeCongé Type de congé varchar 255
dateDebut Date de debut du congé date /
dateFin Date de fin du congé date /
nom Nom de personnel varchar 255
prénom Prénom de personnel varchar 255
photo Photo de personnel varchar 255
genre Genre de personnel (femme / homme) varchar 255
type_contrat Type de contrat de personnel (CDD, CDI) varchar 3
date_deb_contrat Date de début de contrat de personnel date /
date_fin_contrat Date de fin de contrat de personnel date /

Table 2.2 – Dictionnaire de données

22
Diagramme de classes

Figure 2.8 – Diagramme de classes

Passage au modèle relationnel

Nous avons créé un modèle relationnel qui décrit la structure de notre base de données
à partir du Diagramme de classe. Pour cela nous avons suivi les règles de passage au modèle
relationnel :
• Règle 1 :
– Chaque classe devient une relation ayant pour clé primaire son identifiant.
– Chaque propriété se transforme en attribut.
• Règle 2 :

23
 – Toute association hiérarchique de type [1, n] se traduit par une clé étrangère.
– La clé primaire correspondant à l’entité mère (côté n) migre comme clé étrangère
dans la relation correspondant à l’entité fille (côté 1).
• Règle 3 :
– Toute association non hiérarchique de type [n, n] ou de dimension > 2 devient
une relation.
– La clé primaire est formée par la concaténation des identifiants des entités reliées.
• Transformation de la relation d’héritage par la classe mère
– Seule la classe mère est représentée par une relation (ses classes filles ne sont pas
représentées par des relations).
– Tous les attributs de chaque classe fille sont réintégrés au niveau de la classe mère.
– La clé primaire de la classe mère est utilisée pour identifier la relation.
– Un attribut supplémentaire de discrimination t (pour "type"), est ajouté à la
classe mère, afin de distinguer les tuples. Cet attribut est de type énumération et
a pour valeurs possibles les noms de la classe mère ou des différents classes filles.

Schéma relationnel du système

Voici le modèle élaboré par l’application des règles précédentes :
• Poste (id_poste, nom_partition, nom_poste, capacité_poste, atelier, id_user*)
• Utilisateur (id_user, rôle, password, id_service*, t)
• Service (id_service, nom_service, id_user*)
• Besoin ( id_besoin, id_user_émetteur*, id_user_récepteur*, recepteur, heure,
duree, date, validation, confirmation)
• Personnel (matricule, nom, prénom, fonction, photo, genre(f/h), type_contrat, date_deb_contrat,
date_fin_contrat, atelier)
• Matrice_de_compétences (id, compétence, matricule*, id_poste*, id_user*)
• Info_Facultatif (info, typeInfo, id_besoin*)
• Absent (typeCongé, dateDebut, dateFin, matricule*)
• Historique_affectation_service (id_service*, matricule*, id_user*,date, heur)
• Historique_affectation_poste ( id_poste*, matricule*, id_user*,date, heur)
• Demande_Besoin ( id_user*, id_besoin*)

24
2.6 Conclusion
Au cours de ce chapitre, nous avons effectué une étude approfondie pour modéliser
notre système à l’aide d’UML, en définissant ses aspects fonctionnels et structurels. Cette
démarche nous a permis de mettre en place une implémentation claire et simple que nous
présenterons dans le prochain chapitre.

25
CHAPITRE 3

RÉALISATION ET IMPLÉMENTATION

3.1 Introduction
Ce chapitre se concentre sur la solution qui traite la structure de l’application web et
la transition du modèle logique au modèle physique. Nous commençons par décrire l’archi-
tecture, les langages et les outils utilisés. Ensuite, nous abordons les différentes interfaces de
notre application.

3.2 Architecture du système

Figure 3.1 – Architecture globale de l’application web

26
3.3 Langages et outils utilisés
Nous allons présenter les différents langages et outils que nous avons utilisés lors du
développement de notre application.

3.3.1 Visual Studio Code

Visual Studio Code est un éditeur de code simplifié, qui est
gratuit et développé en open source par Microsoft. Il fonctionne
sous Windows, mac OS et Linux. Il fournit aux développeurs à la
fois un environnement de développement intégré avec des outils
permettant de faire avancer les projets techniques, de l’édition,
à la construction, jusqu’au débogage. Vs code est développé avec
le Framework Electron et conçu principalement pour développer
des projets avec Javascript, [Link] ou encore TypeScript. [1]
3.3.2 HTML
HTML est un langage informatique qui permet de composer
des pages web. Ce langage est utilisé pour créer des pages web.
L’acronyme signifie HyperText Markup Language, ce qui signifie
en français "langage de balisage d’hypertexte". Cette significa-
tion porte bien son nom puisqu’effectivement ce langage permet
de réaliser de l’hypertexte à base d’une structure de balisage. [2]
3.3.3 CSS
CSS signifie Cascading Style Sheets, ce qui peut se traduire par
"feuilles de style en cascade" en français. Il s’agit de fichiers
contenant des instructions relatives à la mise en forme et le style
des pages web. Ce langage sert principalement au développement
de sites web. [3]
3.3.4 JSX
JSX permet de faciliter la syntaxe pour les développeurs, il per-
met d’insérer facilement du HTML dans le JS en réduisant au
maximum le superflu. Il va être possible d’insérer des variables
afin de dynamiser le pseudo-code HTML qui sera rendu à l’utili-
sateur. [4]
3.3.5 REACT
React est une bibliothèque JavaScript pour créer des interfaces
utilisateurs interactives. Définissez des vues simples pour chaque
état de votre application, et lorsque vos données changeront,
React mettra à jour, de façon optimale, juste les composants
qui en auront besoin. Des vues déclaratives rendent votre code
plus prévisible et plus facile à déboguer. [5]

27
3.3.6 TailwindCss
Tainwind CSS se décrit comme un premier framework CSS
utilitaire. Plutôt que de se concentrer sur la fonctionnalité de
l’élément en cours de style, Tailwind est centré sur la façon dont
il doit être affiché. Cela permet au développeur de tester plus
facilement de nouveaux styles et de modifier la mise en page. [6]
3.3.7 JSON
JSON (JavaScript Object Notation) est un format d’échange
de don nées léger et donc performant. C’est un format de texte
indépendant de tout langage mais utilisant des conventions fa-
milières aux programmeurs de la famille de langages C (incluant
JavaScript et Python notamment). JSON est une syntaxe pour
mettre des données en série tel que des objets, tableaux, nombres,
chaînes de caractères, booléens et valeurs null. Elle est basée sur
la syntaxe de JavaScript. [7]
3.3.8 PHP
PHP « Hypertext Preprocessor » est un langage de scripts gé-
néraliste et Open Source, spécialement conçu pour le dévelop-
pement d’applications web. Il peut être intégré facilement au
HTML. Le code PHP est exécuté sur le serveur, générant ainsi le
HTML, qui sera ensuite envoyé au client. Le client ne reçoit que
le résultat du script, sans aucun moyen d’avoir accès au code qui
a produit ce résultat. [8]
3.3.9 Laravel
Laravel est un puissant framework PHP basé sur le modèle de
conception Modèle-vue-contrôleur, conçu pour les développeurs
qui ont besoin d’une boîte à outils simple et élégante pour créer
des applications web complètes. [9]
3.3.10 Rest Api
API REST (également appelée API RESTful) est une interface
de programmation d’application (API ou API web) qui respecte
les contraintes du style d’architecture REST et permet d’inter-
agir avec les services web RESTful. L’architecture REST (Repre-
sentational State Transfer) a été créée par l’informaticien Roy
Fielding. [10]

28
 3.3.11 XAMPP
Xampp est un ensemble de logiciels qui permet de mettre en
place facilement un serveur Web confidentiel, un serveur FTP et
un serveur de messagerie électronique. Simple d’utilisation, il est
à la porté d’un grand nombre de personnes puisqu’il ne demande
aucune connaissance particulière. [11]
3.3.12 GitHub
GitHub est un service d’hébergement Open-Source, permettant
aux programmeurs et aux développeurs de partager le code in-
formatique de leurs projets afin de travailler dessus de façon col-
laborative. On peut le considérer comme un Cloud dédié au code
informatique. [12]
3.3.13 Lucidchart
Lucidchart est une solution évolutive de création de divers sché-
mas pour les entreprises. Elle permet de réaliser des diagrammes
facilement. Il est possible de réaliser des logigrammes, cartes
conceptuelles, UML ou encore des cartes mentales rapidement.
Bénéficiant d’une bibliothèque de formes exceptionnelle. Lucid-
chart fonctionne en version SaaS peu importe l’ordinateur que
l’on utilise. Que cela Mac, PC et également Linux. [13]

3.4 Présentation du système

Dans la partie finale, nous allons vous montrer quelques captures d’écran des interfaces
de notre application que nous avons développée.

3.4.1 Interface d’accueil

Lorsque l’application est lancée, vous êtes accueillis par une interface principale qui
contient l’affectation de l’atelier pinceau, il y a une barre latérale qui permet à l’utilisateur
de s’authentifier s’il a les droits ou bien voir l’affectation d’atelier rouleau et service.

29
 Figure 3.2 – Page d’acceuil

3.4.2 Interface authentification

Chaque utilisateur peut acceder a son espace selon ses privilèges, il doit d’abord saisir
son role et son mot de passe. Si la saisie est erronée un message d’erreur s’affiche.

Figure 3.3 – Page d’authentification

30
 Figure 3.4 – Message d’erreur "Mot de passe erroné"

3.4.3 Interface administarteur

Si l’utilisateur est un administrateur, il a accès au système pour gérer les comptes des
utilisateurs.

Figure 3.5 – Page de "Supprimer Utilisateur"

31
3.4.4 Interfaces demande besoin
Si l’utilisateur authentifié est un service/responsable de planification, il a la possibilité
de remplir un formulaire pour ajouter demande besoin de personnel.

Figure 3.6 – Formulaire de demande service au responsable planificaiton

Figure 3.7 – Affichage des demandes de service parapport au responsable planification

32
3.4.5 Interfaces téléchargement ordre de fabrication
Des que le responsable de planification s’authentifie, il peut telecharger l’ordre de fa-
brication à l’aide du boutton "Choose file", et valider l’affecation finale. Notre application
va détecter les postes qui sont actifs pour l’affectation automatique.

Figure 3.8 – Téléchargement ordre de fabrication

Figure 3.9 – Detection de poste d’affectation

33
3.4.6 Interface affectation
Lorsque le responsable de production s’authentifié, il a la possibilité de lancer l’affec-
tation automatique en appuyant sur le bouton "Lancer", il pourra également apporter des
modifications, permuter entre les personnels ou bien supprimer l’affectation existante afin
d’en créer une nouvelle manuellement.

Figure 3.10 – Interface de l’affectation

3.4.7 Interface affectation service

L’interface est dédiée au responsable de production, leur permettant de gérer les de-
mandes de besoins. Une fois qu’il reçoit les demandes, il a la possibilité d’affecter des person-
nels aux différents services. Des qu’un personnel affecté à un service, il est automatiquement
retiré de la liste des personnels disponibles.

34
 Figure 3.11 – Affichage des demandes et l’affectation pour les services

Figure 3.12 – Affichage affectation service

3.4.8 Interfaces gestion de la matrice

Avec cette interface, le responsable de production a la possibilité de gérer la matrice.

35
 Figure 3.13 – Page gestion la matrice

• Si le responsable souhaite consulter un personnel, il doit saisir son nom/prénom, et

l’affichage doit montrer ces compétences dans tous les postes de l’atelier.

Figure 3.14 – Page de "Consulter Personnel"

36
3.4.9 Interface historique d’affectation
Cette interface permet aux responsables de productions et de planification de consulter
l’historique d’affectation en saisissant la date du jour pour laquelle ils souhaitent voir les
affectations.

Figure 3.15 – Page d’historique d’affectation

3.5 Conclusion
Dans ce chapitre « implémentation », nous avons présenté les langages et les outils
que notre application s’appuie dessus, nous avons aussi détaillé toutes les fonctionnalités de
notre application web grâce à des captures d’écran et des explications détaillées.

37
 CONCLUSION GÉNÉRALE

En conclusion, ce projet de fin d’études a été une expérience enrichissante et satisfai-

sante. Nous avons réussi à atteindre notre objectif initial qui était d’apporter une solution
pour l’affectation des personnels au poste de travail au sein de l’organisme d’accueil «MI-
NIROS». Au cours de ce projet, nous avons réalisé une analyse approfondie des besoins de
l’entreprise, suivie d’une phase de conception et d’implémentation rigoureuse.
Les résultats obtenus sont significatifs, et notre application répond globalement aux
critères souhaités.
Ce projet nous a également permis d’acquérir des compétences précieuses. Nous avons
approfondi nos connaissances en développement logiciel et en communication en jouant le rôle
de maître d’œuvre. Nous avons appris à collaborer étroitement avec les maîtres d’ouvrage
pour comprendre et exprimer leurs besoins, ce qui a abouti à la création d’un cahier des
charges adéquat.
Bien que notre solution ait apporté des améliorations significatives à l’entreprise «MI-
NIROS», nous identifions quelques recommandations pour optimiser davantage l’applica-
tion. Il serait bénéfique d’élargir le champ de l’application en dynamisant les ateliers. De
plus, l’intégration d’analyses supplémentaires en exploitant au maximum les donnees pour-
rait fournir des informations précieuses pour une meilleure prise de décision.
En somme, ce projet nous a permis de mettre en pratique nos connaissances acadé-
miques, d’acquérir de nouvelles compétences et de contribuer de manière concrète à l’amé-
lioration des processus de l’entreprise «MINIROS». Nous sommes fiers du travail accompli
et confiants dans les perspectives d’avenir de notre solution.

38
 BIBLIOGRAPHIE

[1] Visual Studio Code : l’éditeur de code gratuit et complet de Microsoft — blogdumode-
[Link]. [Link] studio- code/.
[Accessed 25-May-2023].
[2] Tony Archambeau. [Link]. [Link] [Accessed
25-May-2023].
[3] Qu’est-ce que le CSS et quelle est son lien avec l’HTML ? — [Link]. https :
//[Link]/dictionnaire-du-web/css. [Accessed 26-May-2023].
[4] Qu’est ce que le JSX en [Link], exemples et fonctionnalités — [Link].
[Link] [Accessed 27-May-2023].
[5] React – Une bibliothèque JavaScript pour créer des interfaces utilisateurs — [Link].
[Link] [Accessed 26-May-2023].
[6] markdefalco. What is Tailwind CSS — [Link]. https : / / learn .
[Link]/en- us/shows/web- wednesday/what- is- tailwind- css. [Acces-
sed 26-May-2023].
[7] Présentation de JSON et utilisation en JavaScript - Pierre Giraud — [Link].
[Link] [Link]/javascript- apprendre- coder- cours/json/.
[Accessed 26-May-2023].
[8] PHP : Quapos ;est ce que PHP ? - Manual — [Link]. [Link]
fr/[Link]. [Accessed 26-May-2023].
[9] Laravel - The PHP Framework For Web Artisans — [Link]. [Link]
com/docs/10.x. [Accessed 26-May-2023].
[10] Une API REST, qu’est-ce que c’est ? — [Link]. [Link]
topics/api/what-is-a-rest-api. [Accessed 26-May-2023].
[11] XAMPP | Pack Logiciel Libre de l’entreprise. [Link]
fr/[Link]?logiciel44. [Accessed 26-May-2023].
[12] GitHub : qu’est-ce que c’est et comment apprendre à l’utiliser ? — [Link].
[Link] [Accessed 26-May-2023].
[13] Lucidchart Avis clients, aperçu des fonctionnalités | Appvizer. [Link]
fr/operations/business-process/lucidchart. [Accessed 26-May-2023].