Pfe Med Yassine Hadda 2023

Dédicaces
Je tiens à dédier ce travail à mes chers parents, Mohamed Riadh et Bassma, qui ont
toujours été mes piliers dans la vie et dans mes études. Leurs sacrifices, leur amour incondi-
tionnel, leur soutien indéfectible et leur confiance en moi ont été ma source d’inspiration et
de motivation tout au long de ce parcours académique. Je ne pourrai jamais assez exprimer
ma gratitude pour tout ce qu’ils ont fait pour moi, mais je leur dédie ce travail en signe de
reconnaissance et d’affection. Que Dieu leur accorde santé, bonheur et longue vie.
Je dédie également ce travail à mon frère Zied et ma sœur Abir, qui ont été des compa-
gnons fidèles tout au long de ma vie. Leurs encouragements, leur soutien et leur amour ont
été essentiels pour mon parcours et je leur en suis éternellement reconnaissant.
Enfin, je tiens à remercier toutes les personnes qui ont cru en moi, qui m’ont soutenu et
encouragé tout au long de mes études. Ma grande famille, mes amis, mes enseignants, mes
collègues et mes proches, vous avez tous joué un rôle important dans ma vie et dans ma
réussite. Cette dédicace est pour vous, pour vous témoigner ma gratitude pour tout ce que
vous avez fait pour moi. Que ce travail soit le fruit de votre soutien et de votre confiance en
moi, et qu’il vous rende fiers comme vous m’avez rendu fier.
i
Remerciements
Je tiens tout d’abord à exprimer ma gratitude à Dieu qui m’a guidé tout au long de ce
travail.
Mes remerciements les plus sincères vont également à mon encadrante, Mme Amira
Dhokar, pour sa contribution inestimable à ce projet. Ses conseils avisés et sa disponibilité
constante ont grandement enrichi mes réflexions et ont contribué à l’aboutissement de ce
travail.
Je tiens à exprimer ma reconnaissance envers M. Ali Bayoudh, mon superviseur chez
Diginov, pour son soutien tout au long de ce travail. Je suis fier de l’avoir élaboré avec lui
et je suis infiniment reconnaissant pour le temps qu’il m’a consacré. Ses conseils avisés ont
grandement contribué à l’aboutissement de ce travail, et je tiens à exprimer ma gratitude
pour sa contribution.
Je tiens à exprimer ma profonde gratitude envers tous les enseignants qui m’ont guidé et
enseigné au cours de mes années d’études. Leurs connaissances, leur expertise et leur passion
pour l’enseignement ont été essentiels pour ma formation académique et personnelle. Chaque
enseignant a contribué à ma croissance et à ma compréhension du monde, et je suis très
reconnaissant pour tout ce qu’ils ont fait pour moi. Je leur suis redevable pour leur patience,
leur soutien et leur encouragement constant. Mes années d’études ont été une expérience
inoubliable grâce à leur dévouement et leur passion pour l’enseignement, et je leur en suis
éternellement reconnaissant.
Je tiens également à remercier les membres du jury d’avoir accepté d’évaluer ce projet,
ainsi que tous ceux qui ont contribué de près ou de loin à sa réalisation. Leur soutien et
leur expertise ont été précieux pour la réussite de ce travail. Je suis reconnaissant pour leur
temps et leur engagement envers ce projet.
ii
Table des matières
Introduction Générale 1
1 Cadre général du projet 3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 DIGINOV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Expertises de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.1 Choix de la méthodologie de travail . . . . . . . . . . . . . . . . . . . 8
1.4.2 Organisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Spécification des besoins 13

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Analyse et Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.3 Besoin non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Conduite du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Équipes et rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Le Backlog produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Prioritaire Product Backlog . . . . . . . . . . . . . . . . . . . . . . . 18
iii
Table des matières
2.3.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4 Architectures de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Environnement de développement et outils . . . . . . . . . . . . . . . . . . . 24
2.5.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.2 Environnement technique . . . . . . . . . . . . . . . . . . . . . . . . 24
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Back-End 30
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1 Objectif du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1 Diagramme général de cas d’utilisation . . . . . . . . . . . . . . . . . 31
3.3.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4 Revue du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4 Front-End "Administrateur" 42
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Objectif du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Diagrammes de cas d’utilisation raffinés . . . . . . . . . . . . . . . . . . . . . 45
4.5 Diagramme de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5.1 Diagramme de séquence « Authentification » . . . . . . . . . . . . . . 51
4.5.2 Diagramme de séquence « Ajouter utilisateur » . . . . . . . . . . . . 52
4.5.3 Diagramme de séquence « Ajouter catégorie » . . . . . . . . . . . . . 53
4.5.4 Diagramme de séquence « Ajouter publication » . . . . . . . . . . . . 54
iv
Table des matières
4.6 Revue du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.7 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5 Front-End "Utilisateur" 59
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1 Objectif du Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4 Diagrammes de cas d’utilisation raffinés . . . . . . . . . . . . . . . . . . . . . 61
5.5 Diagramme de séquences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5.1 Diagramme de séquence « Ajouter publication » . . . . . . . . . . . . 65
5.5.2 Diagramme de séquence « Supprimer publication » . . . . . . . . . . 66
5.5.3 Diagramme de séquence « Modifier publication » . . . . . . . . . . . 67
5.5.4 Diagramme de séquence « Voter » . . . . . . . . . . . . . . . . . . . . 68
5.6 Revue du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.7 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6 Intégration d’un Système de Recommandation basé sur l’API OpenAI 73

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.1 Objectif du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2 Backlog du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3 Système de recommandation : Définition et avantages . . . . . . . . . . . . . 74
6.4 Etude théorique des modèles d’OpenAI . . . . . . . . . . . . . . . . . . . . . 75
6.4.1 Présentation des modèles d’openAI . . . . . . . . . . . . . . . . . . . 75
6.4.2 Etude comparative entre les modèles d’openAI . . . . . . . . . . . . . 76
6.4.3 Choix du modèle openAI à adopter . . . . . . . . . . . . . . . . . . . 77
6.5 Etude pratique : utilisation et intégration de l’API text-davinci-003 dans DI-
GISTACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5.1 Workflow d’échange entre DIGISTACK et OpenAI . . . . . . . . . . 78
6.5.2 Configuration, mise en place et intégration du modèle OpenAI . . . . 79
v
Table des matières
6.5.3 Evaluation du modèle utilisé . . . . . . . . . . . . . . . . . . . . . . . 80

6.6 Revue du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.7 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Conclusion Générale 83
Bibliographie 85
Annexe 87
vi
Table des figures
1.1 Logo de Diginov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Méthodologie SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Architecture physique de l’application web [1] . . . . . . . . . . . . . . . . . 22

2.2 Architecture logique de l’application [2] . . . . . . . . . . . . . . . . . . . . . 22
2.3 Architecture de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 React logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 NodeJS logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 ExpressJs logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7 MongoDB logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.8 MongoDB Compass logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.9 Postman logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10 Gitlab logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.11 Visual Studio Code logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.12 Microsoft Teams logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.13 Skype logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.14 Trello logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.15 StarUML logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Diagramme de séquence "Authentification" . . . . . . . . . . . . . . . . . . . 36
3.4 Diagramme de séquence "Ajouter utilisateur" . . . . . . . . . . . . . . . . . 38
3.5 Historique des demandes de fusion (Merge Requests) . . . . . . . . . . . . . 39
3.6 Historique des premiers commits effectués . . . . . . . . . . . . . . . . . . . 39
3.7 Test d’autorisation avec JWT . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.8 Test d’ajout d’un post . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
vii
Table des figures
4.1 Diagramme de cas d’utilisation pour l’Administrateur . . . . . . . . . . . . . 44

4.2 Diagramme de cas d’utilisation s’authentifier . . . . . . . . . . . . . . . . . . 45
4.3 Diagramme de cas d’utilisation «Gérer les utilisateurs» . . . . . . . . . . . . 45
4.4 Diagramme de cas d’utilisation "Gérer les publications" . . . . . . . . . . . . 47
4.5 Diagramme de cas d’utilisation "Gérer les categories" . . . . . . . . . . . . . 49
4.6 Diagramme de séquence «Authentification» . . . . . . . . . . . . . . . . . . 51
4.7 Diagramme de séquence «Ajouter utilisateur» . . . . . . . . . . . . . . . . . 52
4.8 Diagramme de séquence «Ajouter catégorie» . . . . . . . . . . . . . . . . . . 53
4.9 Diagramme de séquence «Ajouter publication» . . . . . . . . . . . . . . . . . 54
4.10 Page login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.11 Page d’accueil «Admin» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.12 Page de gestion des utilisateurs «Admin» . . . . . . . . . . . . . . . . . . . . 56
4.13 Page de gestion des challenges «Admin» . . . . . . . . . . . . . . . . . . . . 56
4.14 Page de gestion des workshops «Admin» . . . . . . . . . . . . . . . . . . . . 57
4.15 Page de gestion des formations «Admin» . . . . . . . . . . . . . . . . . . . . 57
5.1 Diagramme de cas d’utilisation «Utilisateur» . . . . . . . . . . . . . . . . . . 61

5.2 Diagramme de cas d’utilisation "Gérer les publications" . . . . . . . . . . . . 62
5.3 Diagramme de cas d’utilisation "Consulter les défis" . . . . . . . . . . . . . . 64
5.4 Diagramme de séquence «Ajouter publication» . . . . . . . . . . . . . . . . . 65
5.5 Diagramme de séquence «Supprimer publication» . . . . . . . . . . . . . . . 66
5.6 Diagramme de séquence «Modifier publication» . . . . . . . . . . . . . . . . 67
5.7 Diagramme de séquence «Voter» . . . . . . . . . . . . . . . . . . . . . . . . 68
5.8 Page d’accueil «User» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.9 Page de profil «User» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.10 Page de challenge «User» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.11 Page de publication «User» . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.12 Page des membres «User» . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.13 Page des avatars (hommes) «Utilisateur» . . . . . . . . . . . . . . . . . . . . 71
5.14 Page des avatars (femmes) «Utilisateur» . . . . . . . . . . . . . . . . . . . . 71
6.1 Diagramme de séquence "ajouter publication" avec OpenAI . . . . . . . . . 78
viii
Table des figures
6.2 Fonction "generateChatgptResponse" . . . . . . . . . . . . . . . . . . . . . . 79

6.3 Exemple 1 de réponse générée par la fonction "generateChatgptResponse" . 81
6.4 Exemple 2 de réponse générée par la fonction "generateChatgptResponse" . 81
6.5 Diagramme de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.6 Planification des sprints avec Trello . . . . . . . . . . . . . . . . . . . . . . . 88
6.7 branches Gitlab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.8 Diagramme de cas d’utilisation affiné «Gérer le profil» . . . . . . . . . . . . 90
6.9 Diagramme de cas d’utilisation affiné «Gérer les workshops» . . . . . . . . . 91
6.10 Diagramme de cas d’utilisation affiné «Gérer les défis» . . . . . . . . . . . . 91
6.11 Diagramme de cas d’utilisation affiné «Gérer les formations» . . . . . . . . . 92
6.12 Diagramme de cas d’utilisation affiné «Gérer les notifications» . . . . . . . . 92
6.13 Diagramme de cas d’utilisation affiné «Gérer les discussions» . . . . . . . . . 93
6.14 Diagramme de séquence «Modifier publication» . . . . . . . . . . . . . . . . 101
6.15 Diagramme de séquence «Supprimer publication» . . . . . . . . . . . . . . . 102
6.16 Diagramme de cas d’utilisation affiné «Gérer les discussions» . . . . . . . . . 103
6.17 Diagramme de cas d’utilisation affiné de «Gérer le profil» . . . . . . . . . . . 103
6.18 Diagramme de cas d’utilisation affiné «Consulter les formations» . . . . . . . 104
6.19 Diagramme de cas d’utilisation affiné «Gérer les notification» . . . . . . . . . 104
6.20 Diagramme de cas d’utilisation affiné «Consulter les workshops» . . . . . . . 105
6.21 Diagramme de cas d’utilisation affiné «S’authentifier» . . . . . . . . . . . . . 105
ix
Liste des tableaux
1.1 Tableau comparative des solutions existantes . . . . . . . . . . . . . . . . . . 8
2.1 Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2 Description textuelle du cas d’utilisation «S’authentifier» . . . . . . . . . . . 35

4.2 Description textuelle du cas d’utilisation "Ajouter utilisateur" . . . . . . . . 46
4.3 Description textuelle du cas d’utilisation "Gérer les publications" . . . . . . 49
4.4 Description textuelle du cas d’utilisation "Gérer les categories" . . . . . . . . 50

5.2 Description textuelle du cas d’utilisation «Gérer les notification» . . . . . . . 63
5.3 Description textuelle du cas d’utilisation "Consulter les défis" . . . . . . . . 65

6.2 Liste de de quelques modèles existants d’openAI [3] . . . . . . . . . . . . . . 76
6.3 Etudes comparative entre les différentes modèles testés [3] . . . . . . . . . . 77

6.5 Description textuelle du cas d’utilisation «Gérer les workshops» . . . . . . . 95
6.6 Description textuelle du cas d’utilisation «Gérer les défis» . . . . . . . . . . 96
6.7 Description textuelle du cas d’utilisation «Gérer le profil» . . . . . . . . . . . 97
6.8 Description textuelle du cas d’utilisation «Gérer les formations» . . . . . . . 98
6.9 Description textuelle du cas d’utilisation «Gérer les notifications» . . . . . . 99
6.10 Description textuelle du cas d’utilisation «Gérer les discussions» . . . . . . . 100
x
Liste des tableaux

6.12 Description textuelle du cas d’utilisation «Gérer le profil» . . . . . . . . . . . 108
6.13 Description textuelle du cas d’utilisation «Consulter les formations» . . . . . 108
6.14 Description textuelle du cas d’utilisation «Gérer les discussions» . . . . . . . 109
6.15 Description textuelle du cas d’utilisation «Consulter les workshops» . . . . . 110
xi
Liste des acronymes
SEO Search Engine Optimization
BI Business Intelligence
DevOps Development (Dev) and Operations (Ops)
UML Unified Modeling Language
PB Product Backlog
CPU Central Processing Unit
RAM Random Access Memory
OS Operating System
SSD Solid-State Drive
HDD Hard Disk Drive
API Application Programming Interface
JSON JavaScript Object Notation
HTTP HyperText Transfer Protocol
CI Continuous Integration
CD Continuous Delivery
HTTP HyperText Transfer Protocol
CRUD Create Read Update Delete
JWT JSON Web TokenDelete
PO Product Owner
SM Scrum Master
DevTeam Development Team
REST Representational State Transfer
QCM Questionnaire à Choix Multiples
xii
Liste des tableaux
GPT Generative Pre-trained Transformer
TPM Transactions Per Minute
RPM Requests Per Minute
xiii
Introduction Générale
De nos jours, les entreprises sont confrontées à des défis constants en matière de ges-
tion des connaissances et de collaboration entre leurs employés. La rapidité avec laquelle
l’information évolue et se propage rend crucial le développement de solutions efficaces pour
partager les connaissances et favoriser la communication au sein de l’organisation. Dans ce
contexte, la gestion des connaissances devient un enjeu stratégique majeur. Les organisations
comprennent de plus en plus l’importance de capitaliser sur les connaissances et l’expertise de
leurs employés pour stimuler l’innovation, favoriser la prise de décision éclairée et améliorer
la productivité globale.
Cependant, malgré cette prise de conscience, de nombreuses entreprises se heurtent à des
obstacles lorsqu’il s’agit de mettre en place des processus efficaces de partage des connais-
sances. Les informations sont souvent dispersées dans divers systèmes, les employés ont du
mal à trouver rapidement les informations pertinentes, et la collaboration entre les équipes
peut être entravée par des barrières communicationnelles.
Dans ce contexte, notre projet de fin d’études, élaboré au sein de l’entreprise DIGINOV,
vise à proposer une application web d’un système permettant à tous les membres de l’équipe
de partager et d’enrichir leurs connaissances techniques via un système de communication
interne et de rester ainsi à la pointe de la technologie.
Ce rapport respectera le processus Agile Scrum, qui favorise une approche itérative et
collaborative dans le développement des applications. La structure du rapport suivra les
principales phases de ce processus et sera structuré en 5 chapitre :
Dans le premier chapitre, nous mettrons en avant l’organisme d’accueil dans lequel le
projet a été réalisé. Nous présenterons également le cadre du projet, en décrivant le contexte
et les objectifs à atteindre. De plus, nous détaillerons la méthodologie de travail adoptée, en
mettant en évidence l’utilisation de la méthode Agile Scrum et les avantages qu’elle offre en
termes de flexibilité, de collaboration et d’adaptabilité aux changements.
Le deuxième chapitre sera consacré à la phase d’analyse du projet. Nous aborderons
l’architecture du produit, en décrivant les différentes composantes et leur interaction. Nous
1
Introduction Générale
présenterons également les outils et les technologies qui ont été adoptés pour le dévelop-
pement de l’application. Ensuite, nous nous concentrerons sur l’identification des besoins
fonctionnels et non fonctionnels, en prenant en compte les exigences spécifiques de l’entre-
prise. Cette analyse approfondie nous permettra d’établir le Product Backlog, qui répertorie
les fonctionnalités prioritaires de l’application. Enfin, nous planifierons les sprints nécessaires
pour la mise en œuvre de l’application, en définissant les objectifs et les tâches à accomplir
pour chaque itération.
Le troisième chapitre fera l’objet d’un premier sprint du projet, axé sur l’implémentation
de l’acteur Utilisateur dans notre application de partage de connaissances. Ce sprint initial
vise à fournir aux utilisateurs une interface conviviale et des fonctionnalités de base pour
interagir avec le système et a pour objectif de...
Dans le quatrième chapitre, nous aborderons le deuxième sprint de notre projet, qui se
concentrera sur l’acteur Administrateur de l’application. Ce sprint vise à mettre en place les
fonctionnalités et les outils nécessaires pour permettre à l’administrateur de gérer efficace-
ment l’application et d’assurer sa bonne utilisation.
Dans le cinquième chapitre, nous aborderons le troisième sprint de notre projet, qui
se concentrera sur le développement d’un système de recommandation. Ce sprint vise à
mettre en place un mécanisme intelligent qui permettra aux utilisateurs de recevoir des
recommandations personnalisées et pertinentes en fonction de leurs préférences et de leur
historique d’utilisation.
La dernière partie du rapport portera sur la conclusion générale du projet qui mettra en
évidence les différents atouts de ce travail ainsi que les perspectives visant à améliorer notre
produit.
2
Cadre général du projet
1
Introduction
Dans ce chapitre, nous aborderons deux points essentiels. Tout d’abord, nous présente-
rons l’entreprise d’accueil, DIGINOV, en mettant en évidence ses caractéristiques et son
contexte. Ensuite, nous nous concentrerons sur le contexte du projet en décrivant la tech-
nologie que nous allons utiliser. Par la suite, nous présenterons le projet en exposant la
problématique qui se pose, et nous envisagerons une solution appropriée. Enfin, nous justi-
fierons le choix de la méthodologie adoptée pour la réalisation du projet, en expliquant les
raisons qui nous ont conduits à opter pour cette approche spécifique.
1.1 Présentation de l’organisme d’accueil

Le présent travail s’inscrit dans le cadre du projet de fin d’études en vue de l’obtention
du diplôme nationale d’ingénieur en génie informatique de l’École Polytechnique Sousse. Il
a été réalisé au sein de la société DIGINOV et a duré 4 mois.
3
Chapitre 1. Cadre général du projet
1.1.1 DIGINOV
DIGINOV est une société de développement et de conseil informatique, fondée en 2016,

qui s’est rapidement imposée comme l’un des acteurs les plus innovants et performants du
secteur en Tunisie. L’entreprise se distingue par son approche axée sur les besoins spécifiques
de chaque client et sa capacité à offrir des solutions sur mesure. DIGINOV compte une équipe
de professionnels expérimentés et hautement qualifiés, spécialisés dans des domaines tels que
le developemment web et mobile, l’optimisation des moteurs de recherche (SEO), ainsi que
la mise en place de solutions pour un système ERP en ligne pour les entreprises. Grâce à
son expertise et à son passion pour l’innovation, l’équipe de DIGINOV aide les entreprises
à transformer leurs présences en ligne en une véritable source de croissance et de succès.
DIGINOV est une entreprise qui s’engage à fournir des services de qualité supérieure et à
établir des relations de confiance à long terme avec ses clients [4].
Figure 1.1 – Logo de Diginov
1.1.2 Expertises de l’entreprise
DIGINOV propose une gamme variée de services pour répondre aux besoins de ses clients.
Ses compétences et son savoir-faire lui permettent de fournir des solutions adaptées et effi-
caces dans les domaines suivants :
• Mobile : L’équipe de développement mobile possède une grande expertise dans la
conception et la création d’applications pour les plateformes iOS et Android. Elle
assure également l’optimisation de sites web pour les appareils mobiles.
• Web : Les experts en développement web travaillent en étroite collaboration avec leurs
4
clients pour répondre à leurs besoins en matière de sites web dynamiques, d’applica-
tions web, d’e-commerce et d’optimisation pour les moteurs de recherche.
• BI : Des solutions de Business Intelligence sur mesure sont offertes pour aider les
clients à prendre des décisions éclairées grâce à des analyses approfondies des données.
• DevOps : L’équipe DevOps se concentre sur l’automatisation des processus de déve-
loppement et de déploiement de logiciels, pour permettre à ses clients de gagner du
temps et d’améliorer leur efficacité.
• Robotics : Une grande expérience dans le domaine de la robotique, avec une exper-
tise dans la conception, la programmation et l’intégration de robots pour diverses
applications industrielles et commerciales.
• ERP : Des solutions ERP personnalisées sont proposées pour aider les clients à amé-
liorer leur efficacité opérationnelle et leur rentabilité, en automatisant leurs processus
métiers clés.
1.2 Contexte du projet

Dans le monde professionnel en constante évolution d’aujourd’hui, les organisations cherchent
en permanence à optimiser leur communication interne pour favoriser la collaboration et
améliorer l’efficacité de leurs équipes. Parmi les outils de communication modernes, les fo-
rums internes se sont révélés être des solutions précieuses pour faciliter les échanges au sein
d’une société. Ces plateformes de messagerie instantanée offrent un espace de conversation
en temps réel, permettant aux employés de communiquer rapidement et facilement, que ce
soit pour des discussions informelles, des partages de documents, des corrections d’erreurs
dans les codes ou des prises de décisions importantes.
Le contexte de réalisation d’un forum interne dans une société est étroitement lié aux
besoins d’une communication efficace et transparente au sein de l’organisation. Cet outil
moderne favorise la collaboration, encouragent l’engagement des employés et optimisent la
productivité en réduisant les obstacles liés à la distance géographique et à la hiérarchie. En
adoptant un forum interne, une société s’engage à créer un environnement de travail moderne
et agile, propice à l’innovation et à la réussite collective.
5
1.3 Présentation du projet

Ce projet vise à développer une plateforme de blog interne qui permettra à tous les
membres de l’équipe de partager et d’enrichir leurs connaissances techniques et de développer
des méthodes de travail solides.
1.3.1 Problématique
Le partage des connaissances entre les employés est un aspect important de la culture de
l’entreprise moderne, en particulier dans les domaines de la technologie et du développement
informatique. Cependant, les méthodes traditionnelles telles que les formations en salle de
classe et les manuels imprimés peuvent être coûteuses et peu efficaces. D’autre part, le
manque de communication interne efficace, la difficulté d’accès à l’information pertinente,
le faible engagement et la collaboration entre les employés peuvent affecter d’une manière
considérable le rendement de l’équipe au sein d’une entreprise.
Le projet consiste à mettre en oeuvre en un système de blog interne pour permettre
aux employés de partager leurs connaissances et d’acquérir de nouvelles compétences, tout
en favorisant la collaboration et la création d’une communauté de partage. La plateforme
permettra aux employés de poser des questions sur le codage, de partager des connaissances
et de participer à des défis et des formations.
Cependant, les questions qui se posent dans ce contexte sont les suivantes : Comment
s’assurer que les employés s’engagent dans cette plateforme ? Et comment garantir que les
connaissances partagées sont pertinentes et de qualité ?
Nous présenterons dans ce qui suit quelques solutions existantes ainsi que notre solution
proposée.
1.3.2 Étude de l’existant
L’étude du marché est une phase essentielle de tout projet. Elle consiste à comprendre et
analyser les solutions existantes et à mener une analyse critique pour déterminer les faiblesses
et les forces de chaque solution existante. Cela permet d’identifier les besoins du projet et de
les prendre en compte lors des phases de conception et de réalisation de notre application.
Dans cette section, nous présenterons quelques-unes des applications existantes qui sont
6
déjà utilisées pour partager et enrichir les connaissances techniques.

Il existe une panoplie de solutions, parmi lesquels nous pouvons citer Microsoft Teams et
Skype.
1.3.3 Critique de l’existant
1.3.3.1 Microsoft Teams
Services offerts
• Microsoft Teams permet de mener des conversations privées en groupe et de par-
tager différents sortes de contenus. Cette application offre également la possibilité
d’organiser des réunions et des projets avec des équipes différentes.[5].
Critiques
• Il est contrôlé par Microsoft, et non par l’organisation,
• Il consomme beaucoup de ressources système,
• Il possède une interface utilisateur parfois confuse.
1.3.3.2 Skype
Services offerts
• La technologie de Skype est un programme intensif en réseau. C’est l’une des inven-
tions en ligne les plus populaires aidant à la communication des entreprises, de la
famille et des amis. Il est totalement gratuit.[6].
Critiques
• Il est généralement utilisé pour reconnecter les clients et les entreprises pour tenir des
réunions et des conférences.
• Il supporte au maximum 25 personnes dans un groupe de discussion.
1.3.3.3 Solution proposée
DIGINOV s’efforce toujours de moderniser la réalisation de ses projets tout en adoptant

les dernières innovations afin de satisfaire ses clients.
dans ce cadre, DIGINOV a proposé un projet intitulé DIGISTACK,qui permet aux
employés de poser des questions, de répondre aux questions des autres, de partager des
7
connaissances, de participer à des challenges, des formations et des workshops, et de gagner

des badges et des scores en fonction de leur activité sur la plateforme. L’application doit être
conviviale et facile à utiliser, tout en offrant des fonctionnalités de sécurité pour protéger les
données de l’entreprise.
1.3.3.4 Etude comparative entre les solutions
Le tableau 1.1 présente le résultat d’une étude comparative entre les différentes solutions
en se basant sur les critères définis précédemment.
Flexibilité Convivialité Fonctionnalités Sécurité Contrôle de

l’organisation
Microsoft × ✓ × × ×
Teams
Skype × ✓ × × ×
DigiStack ✓ ✓ ✓ ✓ ✓
Table 1.1 – Tableau comparative des solutions existantes
1.4 Méthodologie de travail

La réalisation du projet dans les délais impartis est la principale préoccupation de chaque
équipe de développement de logiciels. L’un des problèmes les plus fréquemment rencontrés
lors de la construction de logiciels est la mauvaise spécification et les changements brusques
des besoins. Cela peut affecter non seulement l’équipe de développement en créant un envi-
ronnement stressant, mais aussi le temps passé sur le projet et par conséquent, les délais de
livraison dépassés. L’utilisation d’une méthodologie est importante pour éviter toute pertur-
bation en termes de délais car elle aide à planifier le travail de manière efficace.
1.4.1 Choix de la méthodologie de travail
Agile est un processus par lequel une équipe peut gérer un projet en le divisant en
plusieurs étapes et en impliquant une collaboration constante avec les parties prenantes
8
ainsi qu’une amélioration et une itération continues à chaque étape. La méthodologie Agile
commence par la description par les clients de la façon dont le produit final sera utilisé et
quel problème il résoudra.[7]
Cette méthode est basée sur 4 valeurs principales :
• Les individus et les interactions plutôt que les processus et les outils,
• Un logiciel fonctionnel plutôt qu’une documentation exhaustive,
• La collaboration avec le client plutôt que la négociation de contrat,
• Répondre au changement plutôt que suivre un plan.
DIGINOV s’appuie sur la meilleure méthodologie pour la réalisation de ses projets :

SCRUM.
1.4.1.1 Présentation de la méthodologie SCRUM
Scrum est une méthodologie agile de gestion de projet utilisée pour les projets de déve-
loppement de logiciels dans le but de fournir une nouvelle capacité logicielle toutes les 2-4
semaines. La figure 1.2 présente un diagramme qui décrit le processus de la méthodologie
SCRUM :[8]
Figure 1.2 – Méthodologie SCRUM
9
1.4.2 Organisations
La méthodologie Scrum est définie par des rôles d’équipe, des événements, des artefacts
et des règles. Ci-dessous, nous détaillerons le rôle de chacun :
L’équipe Scrum :
• Le Product Owner : généralement un client interne ou externe, ou un porte-parole
pour le client, il y a seulement un Product Owner. Il est ultimement responsable de la
gestion du backlog du produit et de l’acceptation des incréments de travail terminés.
• Le Scrum Master : est le leader servant du Product Owner, de l’équipe de développe-
ment et de l’organisation. Il s’assure que l’équipe adhère à la théorie, aux pratiques et
aux règles de Scrum et protège l’équipe en faisant tout ce qui est possible pour aider
l’équipe à performer au plus haut niveau.
• L’équipe de développement : l’équipe de développement est un groupe auto-organisé et
interfonctionnel armé de toutes les compétences nécessaires pour livrer des incréments
livrables à la fin de chaque sprint.
Événements Scrum :
• Le Sprint : Un sprint est une période limitée dans le temps au cours de laquelle un
travail spécifique est achevé et prêt pour examen. Les sprints durent généralement de
2 à 4 semaines, mais peuvent être aussi courts qu’une semaine.
• La planification du sprint : Les réunions de planification d’équipe sont des événements
limités dans le temps qui déterminent les éléments du backlog du produit qui seront
livrés et la manière dont le travail sera réalisé.
• La réunion quotidienne : La réunion quotidienne est une courte réunion de commu-
nication (pas plus de 15 minutes) au cours de laquelle chaque membre de l’équipe
couvre rapidement et de manière transparente les progrès depuis la dernière réunion,
le travail planifié avant la prochaine réunion et tout obstacle qui pourrait bloquer sa
progression.
• La revue de sprint : La revue de sprint est l’événement de "monstration" ou de
présentation pour l’équipe afin de présenter le travail accompli pendant le sprint. Le
Product Owner vérifie le travail par rapport aux critères d’acceptation prédéfinis et
accepte ou rejette le travail. Les parties prenantes ou clients donnent des commentaires
pour garantir que l’incrément livré répond aux besoins commerciaux.
10
• La rétrospective : La rétrospective, ou Retro, est la dernière réunion d’équipe du sprint

pour déterminer ce qui s’est bien passé, ce qui ne s’est pas bien passé et comment
l’équipe peut s’améliorer dans le prochain sprint. Assistée par l’équipe et le Scrum
Master, la rétrospective est une occasion importante pour l’équipe de se concentrer
sur sa performance globale et d’identifier des stratégies d’amélioration continue de ses
processus.
Artefacts Scrum :
• Product Backlog : Le Product Backlog est le document le plus important qui décrit
chaque exigence pour un système, un projet ou un produit. Le Product Backlog peut
être considéré comme une liste de tâches comprenant des éléments de travail, chacun
produisant une livraison ayant une valeur commerciale.
• Sprint Backlog : Le Sprint Backlog est la liste spécifique d’éléments provenant du
Product Backlog qui doivent être achevés lors d’un sprint.
• Incrément : Un incrément est la somme de tous les éléments du Product Backlog qui
ont été achevés depuis la dernière livraison logicielle. Bien qu’il revienne au Product
Owner de décider quand un incrément est livré, il est de la responsabilité de l’équipe
de s’assurer que tout ce qui est inclus dans un incrément est prêt à être livré.
Règles de Scrum :
• Les règles de l’agile Scrum devraient être entièrement déterminées par l’équipe et
régies par ce qui fonctionne le mieux pour ses processus. Les meilleurs coachs agiles
conseilleront aux équipes de commencer avec les événements Scrum de base énumérés
ci-dessus, puis d’inspecter et de s’adapter en fonction des besoins uniques de l’équipe,
de sorte qu’il y ait une amélioration continue de la façon dont les équipes travaillent
ensemble.[9]
11
Conclusion
Ce chapitre a dressé un portrait général de l’entreprise et de ses services, ainsi que du
contexte dans lequel notre projet s’inscrit. Nous avons mis en évidence le problème que
nous cherchons à résoudre, en citant des exemples concrets de difficultés rencontrées par
les utilisateurs actuels. Nous avons également analysé les faiblesses des applications exis-
tantes et montré pourquoi il est important de développer une nouvelle solution. Enfin, nous
avons présenté la méthodologie que nous avons choisie pour mener à bien notre projet, ainsi
que les objectifs que nous nous sommes fixés. Dans le prochain chapitre, nous aborderons
l’étude préliminaire et la conception architecturale de notre solution, en détaillant les choix
techniques et les spécifications fonctionnelles.
12
Spécification des besoins
2
Introduction
Ce sprint vise à spécifier et à capturer, en premier lieu les besoins nécessaires pour
construire notre système. L’objectif principal est de comprendre les attentes des utilisateurs
et de définir clairement les fonctionnalités essentielles de l’application. Ce sprint décrira les
étapes et les méthodologies utilisées pour capturer et analyser les exigences, établissant ainsi
une base solide pour le développement futur du projet.
La partie suivante sera axée sur la méthodologie choisie pour notre application. Enfin,
nous présenterons la mise en pratique des principes Scrum.
2.1 Analyse et Spécification des besoins

L’application web dont la société DIGINOV veut se doter, doit être opérationnelle, convi-
viale et offrant les informations nécessaires pour l’utiliser aisément. Ainsi, le système à réaliser
doit satisfaire les exigences de l’ensemble des utilisateurs. Nous présentons dans ce qui suit
tous les besoins fonctionnels ainsi que les besoins non fonctionnels de notre système.
13
Chapitre 2. Spécification des besoins
2.1.1 Identification des acteurs
L’application comporte deux principaux acteurs : l’administrateur et l’utilisateur.

Chacun de ces acteurs possède des droits et des fonctionnalités spécifiques au sein du
système.
• L’administrateur : il a le droit d’accéder aux différents compartiments de l’application.
Il est la personne ayant le plus haut niveau de privilège. Cet acteur est capable de
manipuler les fonctionnalités les plus importantes, à savoir la création, la modification
et la suppression de toutes les entités de l’application.
• L’utilisateur (membre de l’équipe DIGINOV) : il a des droits spécifiques, tels que la
consultation et le partage des publications (quel que soit leur type), la gestion du
profil, etc.
2.1.2 Identification des besoins
2.1.2.1 Besoins fonctionnels
Il s’agit des fonctionnalités du système. Ce sont les besoins spécifiant un comportement

d’entrée / sortie du système.
Les actions effectuées par l’administrateur sont :
• Authentification :
— S’authentifier par e-mail et mot de passe
— Réinitialiser son mot de passe oublié
• Gestion du profil
— Gérer son profil (Consulter son profil, modifier son nom, modifier son email, mo-
difier son mot de passe, ajouter un avatar)
• Gestion des utilisateurs
— Gérer les utilisateur (Lister les utilisateur, ajouter un utilisateur, modifier un uti-
lisateur, supprimer un utilisateur)
• Gestion des publications
— Gérer les publications(Consulter une publication, ajouter une publication, modifier
une publication, supprimer une publication)
— Réagir à une publication (vote up/down)
14
— Commenter une publication ( ajouter un commentaire/modifier un commentaire/supprimer

un commentaire/Réagir un commentaire«vote up/down»)
— Rechercher une publication (par tags/Categories...)
• Gestion des commentaires
— Gérer les commentaires (Consulter un commentaire, ajouter un commentaire, mo-
difier un commentaire, supprimer un commentaire, réagir un commentaire«vote
up/down»)
• Gestion des workshops
— Gérer les workshops (lister les workshops, ajouter un worshop, modifier un work-
shop, supprimer un workshop)
• Gestion des défis
— Gérer les défis (Lister les défis, ajouter un défi, modifier un défi, supprimer un
défi)
• Gestion des formations
— Gérer les formation(Lister les formations, ajouter une formation,modifier une for-
mation, supprimer une formation)
• Gestion des catégories
— Gérer les catégories(Lister les catégories, ajouter une catégorie,modifier une caté-
gorie, supprimer une catégorie)
• Gestion des notifications
— Gérer les notification (consulter une notification, supprimer une notification)
• Gestion des discussions
— Gérer les disscussions (Créer une disscussion, consulter une disscussion, supprimer
une disscussion)
Les actions effectuées par l’utilisateur sont :
• Authentification :
— S’authentifier par e-mail et mot de passe
— Réinitialiser son mot de passe oublié
— Gérer son profil (Consulter son profil, modifier son nom, modifier son email, modi-
fier son mot de passe, ajouter un avatar, ajouter des liens LinkedIn/GitHub/Gitlab,
15
Créer une description, consulter son score, consulter son badge)

— Gérer les publications(Consulter une publication, ajouter une publication, modifier
une publication, supprimer une publication, partager une publication)
— Réagir à une publication (vote up/down)
— Commenter une publication ( ajouter un commentaire/modifier un commentaire/supprimer
un commentaire/Réagir un commentaire«vote up/down»)
— Rechercher une publication (par tags/Categories...)
— Gérer les commentaires (Consulter un commentaire, ajouter un commentaire, mo-
difier un commentaire, supprimer un commentaire)
— Gérer les notification (consulter une notification, supprimer une notification)
— Gérer les disscussions (Créer une disscussion, consulter une disscussion, supprimer
une disscussion)
• Consultaion des défis
— Participer à un défi
• Consultation des workshops
— Participer à un workshop
• Consultation des formations
— Participer à une formation
2.1.3 Besoin non fonctionnels
Ce sont les besoins qui permettent d’assurer la qualité des services de l’application :
L’ergonomie : Il faut avoir des interfaces simples, non encombrées, responsives, com-
préhensibles et représentables de point de vue design.
Une contrainte technique : Il faut assurer la cohérence entre les interfaces et le
code doit être extensible et maintenable afin de faciliter toute opération d’amélioration ou
d’optimisation.
La sécurité : L’application doit garantir l’intégrité et la confidentialité des données pour
16
l’utilisateur connecté. La sécurité du système est assurée par l’authentification des membres
via un login et un mot de passe. D’autre part, une déconnexion automatique est assurée
après une période d’inactivité (durée, actions).
La performance : Le temps de réponse doit être le plus court possible et l’application
doit être toujours fonctionnelle
2.2 Conduite du projet avec Scrum

Dans cette partie, nous définirons l’équipe, les rôles et le backlog produit.
2.3 Équipes et rôles

Scrum définit trois rôles :
• Le Product Owner (PO) : « Propriétaire du produit », c’est le représentant des clients
et des utilisateurs.
• Le Scrum Master (SM) : « Leader-serviteur de l’équipe Scrum », il assure globalement
la supervision de l’avancement du projet et des activités de l’équipe. Il veille à écarter
et résoudre tout type de problème que rencontre la Dev Team.
• Development Team (DevTeam) : « Équipe de développement », Les développeurs
chargés de la construction du logiciel et d’en faire une démonstration. Selon le Scrum
Guide, une équipe comporte au minimum trois personnes et au maximum neuf per-
sonnes.
En guise de récapitulatif des rôles Scrum et comment ils seront répartis au cours du guidage
de ce projet, mon encadreur jouera le rôle du PO et SM et la DevTeam sera limitée à une
seule personne qui est moi-même Mohamed Yassine Hadda.
2.3.1 Le Backlog produit
Après avoir identifié les besoins de notre application, nous détaillons dans cette partie
toutes les tâches à effectuer sur le projet, classées par priorité, ce qui conduit à un certain
ordre de réalisation.
17
La priorisation du Product backlog est une tâche primordiale, et pour l’effectuer cor-
rectement, il est essentiel d’établir les critères et la méthode de priorisation des produits. Il
existe de nombreuses techniques de priorisation, pour notre cas, nous avons choisi la méthode
MoSCoW :
• Mo (Must have) - Doit avoir : doit être achevé.
• S (Should have) - Devrait avoir : devrait être achevé si possible.
• Co (Could have) -Pourrait avoir : pourrait être achevé s’il n’y a aucun impact sur les
autres tâches en cours.
• W (Would have) - Devrait avoir : ne sera pas achevé immédiatement mais serait
préférable pour une version ultérieure.
2.3.2 Prioritaire Product Backlog
Le tableau 2.1 suivant répertorie les histoires d’utilisateurs et leurs priorités.
18
ID Les histoires d’utilisateur Priorité

1 En tant qu’administrateur, je peux ajouter, visualiser ou supprimer des Mo
utilisateurs.
2 En tant qu’administrateur, je peux ajouter, visualiser, modifier ou sup- Mo
primer des catégories.
primer des publications.
4 En tant qu’administrateur, je peux ajouter, visualiser, modifier ou sup- S
primer des commentaires.
primer des défis.
primer des workshops.
primer des formations
8 En tant qu’administrateur, je peux visualiser ou supprimer les notifica- Co
tions.
9 En tant qu’administrateur, je peux gérer mon Mo
compte(avatar/fullname/etc..)
10 En tant qu’administrateur, je peux réagir à des publications Mo
11 En tant qu’utilisateur, je peux ajouter, modifier ou supprimer mes pu- Mo
blications
12 En tant qu’utilisateur, je peux visualiser les publications Mo
13 En tant qu’utilisateur, je peux ajouter, visualiser, modifier ou supprimer Mo
mes commentaires
14 En tant qu’utilisateur, je peux visualiser les commentaires Mo
15 En tant qu’utilisateur, je peux réagir à des publications Mo
16 En tant qu’utilisateur, je peux visualiser ou participer à des défis. Mo
17 En tant qu’utilisateur, je peux visualiser ou participer à des workshops S
18 En tant qu’utilisateur, je peux visualiser ou participer à des formations S
19
19 En tant qu’utilisateur, je peux gérer mon compte(avatar/fullname/etc..) Mo

20 En tant qu’utilisateur, je peux visualiser ou supprimer les notifications. Co
21 En tant qu’utilisateur, je peux visualiser mes publications partagées. S
Table 2.1 – Product backlog
2.3.3 Planification des sprints
Le tableau 2.2 présente la planification de notre travail, qui se décompose en quatre

sprints distincts correspondant aux différentes parties du projet : le premier sprint mettra en
évidence la partie "Back-End" de notre système, le deuxième sprint sera consacré au dévelop-
pement du la partie "Front-End" pour l’administration, le troisième sprint se concentrera sur
le développement du la partie "Front-End" pour les utilisateurs, et le quatrième et dernier
sprint est relatif à la réalisation d’un système de recommandation.
Sprint Objectif du sprint Date Dé- Date Fin

but
Sprint 1 : 1. Creation des APIs : 06/02/2023 03/03/2023
Back-End • Authentification et Autorisation
• Gestion des utilisateurs
• Gestion des catégories
• Gestion des workshops
• Gestion des defis
• Gestion des formations
20
Sprint 2 : Front-End
"Administrateur"
1. Implémentation des maquettes 06/03/2023 31/03/2023
• Login page
• Home page
• Team page
• Challenges page
• Workshops page
• Tutorial page
• Category page
2. Intégration/Utilisation des APIs
Sprint 3 : Front-End
"Utilisateur"
1. Implémentation des maquettes 03/04/2023 28/04/2023

• Home page
• Challenges page
• Publication page
• Team page
• Profile page
2. Intégration/Utilisation des APIs
Sprint 4 : Intégration
d’un Système
de Recommandation
01/05/2023 26/05/2023
• Etude théorique des systèmes de re-
commandation
• Choix, intégration, utilisation et test
d’un système de recommandation
Table 2.2 – Planification des sprints
2.4 Architectures de la solution
2.4.1 Architecture physique
En tant qu’architecture physique, nous avons un utilisateur, un serveur d’application

Front-End, un serveur d’application Back-End et un serveur de base de données. Il s’agit
donc d’une architecture en n-tiers qui est présentée comme suit :
21
Figure 2.1 – Architecture physique de l’application web [1]
2.4.2 Architecture logique
L’architecture logique se concentre d’avantage sur la décomposition logique de l’applica-

tion et le regroupement des composants en fonction du type de fonctions et des traitements
qu’ils effectuent, comme le montre la figure 2.2.
Figure 2.2 – Architecture logique de l’application [2]
22
2.4.2.1 Architecture logique côté Back-end
Dans notre étude, nous ne nous intéressons qu’aux plateformes NodeJS, qui utilisent le
framework Express.js. Express.js est un excellent framework pour créer une API REST, mais
il ne nous donne aucune indication sur la façon d’organiser notre projet. Une organisation
correcte de la structure du projet évitera la duplication du code et améliorera la stabilité. Afin
de faire le bon choix, nous avons choisi l’architecture de composants [10] comme architecture
pour notre projet.
Figure 2.3 – Architecture de composants
Un composant est un ensemble de fonctionnalités modulaires, portables, remplaçables et

réutilisables, bien définies, qui encapsule sa mise en œuvre et l’exporte sous forme d’interface
de niveau supérieur. Un composant est un objet logiciel, destiné à interagir avec d’autres
composants, encapsulant certaines fonctionnalités ou un ensemble de fonctionnalités. Il pos-
sède une interface clairement définie et conforme à un comportement recommandé commun
à tous les composants au sein d’une architecture [11].
23
2.4.2.2 Architecture logique côté Front-end
Dans la même optique que pour l’architecture logique côté Back-end, il est important
d’avoir une organisation claire et structurée pour le Front-end. Dans le cas de notre projet,
nous avons opté pour l’architecture de composants également pour le côté Front-end, qui
présente les mêmes avantages que pour le Back-end en termes de modularité, portabilité,
réutilisabilité et maintenabilité.
En résumé, l’architecture de composants est une approche adaptée pour les deux côtés de
notre application web, permettant une meilleure organisation, réutilisation et maintenabilité
du code.
2.5 Environnement de développement et outils

Dans cette section, nous présenterons l’environnement matériel et technique lié à la réa-
lisation de l’application.
2.5.1 Environnement matériel
Durant la réalisation de ce travail, nous avons utilisé un ordinateur MSI avec un système
d’exploitation Windows 11 et les caractéristiques suivantes :
• CPU : Intel Core i5
• RAM : 16 Gb
• OS : 64 Bits
• Disque Dur : 500 Gb SSD + 500 Gb HDD
2.5.2 Environnement technique
Les choix techniques concernant les langages de développement sont primordiaux. Dans
cette optique, cette section se concentrera sur l’étude des différents langages et frameworks
afin de faire un choix judicieux pour la réalisation de notre projet.
Langage de développement :
Le choix du langage de développement sera divisé en deux parties :
24
• Côté Back-End : Il est invisible pour les visiteurs, mais représente une grande partie
du développement d’un projet web. Le Back-End peut être divisé en deux parties
essentielles :
- Serveur
- Base de données
• Côté Front-End : Lorsque nous parlons de Front-End, il s’agit des éléments du site
web que nous voyons à l’écran et avec lesquels nous pouvons interagir.
Pour le Back-End : Afin de faire le bon choix, nous avons étudié la plateforme NodeJS,
et pour la base de données, nous avons choisi MongoDB pour le stockage des données et
MongoDB Compass pour la gestion de la base de données.
• React : est une bibliothèque JavaScript open-source utilisée pour la création d’in-
terfaces utilisateur (UI) interactives et réactives. Il est largement utilisé pour le déve-
loppement d’applications Web.
Figure 2.4 – React logo
25
• NodeJS : est un environnement d’exécution JavaScript côté serveur basé sur le mo-
teur JavaScript V8 de Chrome. Il permet d’exécuter du code JavaScript en dehors
d’un navigateur, ce qui facilite le développement d’applications serveur hautement
évolutives.
Figure 2.5 – NodeJS logo
• ExpressJs : est un framework d’application Web Node.js minimaliste et flexible qui

fournit un ensemble de fonctionnalités pour développer des applications Web. Il est
souvent utilisé en combinaison avec Node.js pour créer des API et des applications
Web.
Figure 2.6 – ExpressJs logo
• MongoDB : est une base de données NoSQL orientée documents. Elle stocke les
données sous forme de documents JSON flexibles plutôt que dans des tables relation-
nelles. MongoDB est réputée pour sa scalabilité et sa facilité d’utilisation.
Figure 2.7 – MongoDB logo
26
• MongoDB Compass : est un outil visuel et intuitif pour explorer et gérer les bases
de données MongoDB. Il permet d’effectuer des requêtes, de visualiser les schémas,
d’analyser les performances et de manipuler les données.
Figure 2.8 – MongoDB Compass logo
• Postman : est un outil de développement et de test d’API. Il permet de tester, de

déboguer et de documenter les API en envoyant des requêtes HTTP personnalisées
et en visualisant les réponses.
Figure 2.9 – Postman logo
• Gitlab : est une plateforme de gestion du cycle de vie des applications qui offre
des fonctionnalités de gestion de code source, de suivi des problèmes, de CI/CD (in-
tégration continue et déploiement continu), et bien plus encore. Il facilite le travail
collaboratif et le développement de logiciels.
Figure 2.10 – Gitlab logo
27
• Visual Studio Code : est un éditeur de code source gratuit et open-source déve-
loppé par Microsoft. Il est très populaire pour le développement d’applications Web
et offre de nombreuses fonctionnalités, extensions et intégrations pour améliorer la
productivité des développeurs.
Figure 2.11 – Visual Studio Code logo
• Microsoft Teams : est une plateforme de communication et de collaboration en

ligne développée par Microsoft. Elle offre des fonctionnalités telles que la messagerie
instantanée, les appels audio et vidéo, le partage de fichiers et la gestion de projets,
ce qui en fait un outil utile pour le travail d’équipe.
Figure 2.12 – Microsoft Teams logo
• Skype : est une application de communication en ligne qui permet les appels audio
et vidéo, les messages instantanés et le partage de fichiers. Elle est largement utilisée
pour les appels personnels et professionnels.
Figure 2.13 – Skype logo
28
• Trello : est un outil de gestion de projet en ligne qui permet de créer des tableaux,
des listes et des cartes pour organiser les tâches, les projets et les flux de travail. Il
offre une vue d’ensemble visuelle des projets et facilite la collaboration au sein des
équipes.
Figure 2.14 – Trello logo
• StarUML : est un logiciel de modélisation UML (Unified Modeling Language) utilisé

pour créer des diagrammes de classes, de séquence, de cas d’utilisation et d’autres
types de diagrammes pour la conception logicielle.
Figure 2.15 – StarUML logo
Conclusion
Dans ce chapitre, nous avons présenté les spécifications des besoins. Cela nous a permis
d’avoir une vision plus claire afin de mettre en évidence les différentes parties de notre
projet. Nous avons aussi présenté les architectures physique et logique de notre application.
Le prochain chapitre sera consacré à la présentation de notre premier sprint consacré au
Back-end.
29
Back-End
3
Introduction
Ce sprint se concentre sur le back-end de notre application DIGISTACK, essentiel à
la communication interne fluide au sein de notre société. Nous visons à renforcer les per-
formances, à optimiser la gestion des données et à développer des fonctionnalités pour une
meilleure expérience utilisateur. Notre objectif est de créer une plateforme de communication
sécurisée et efficace, favorisant la collaboration entre les membres de notre organisation.
3.1 Objectif du sprint

L’objectif est de fournir un produit final prêt à être déployé lors du dernier sprint, en
garantissant l’authentification, la gestion des utilisateurs, des catégories, des publications,
des defis, des formations, des workshops, des commentaires, des notifications, ainsi que la
mise en place d’une fonctionnalité de chat permettant aux utilisateurs de communiquer entre
eux.
30
Chapitre 3. Back-End
3.2 Sprint Backlog

Le tableau suivant représente le Backlog de ce sprint. Il décrit la liste des tâches qui
seront réalisées :
ID Tâches Éstimation (Jour)

1 Authentification et autorisation 4
2 Gestiondes utilisateurs 3
3 Gestion des catégories 2
4 Gestion des publications 3
5 Gestion des workshops 2
6 Gestion des defis 2
7 Gestion des formations 2
8 Gestion du profil 2
9 Gestion commentaires 3
10 Gestion notifications 2
11 Gestion chat 3
Table 3.1 – Backlog du Sprint 1
3.3 Spécification fonctionnelle

La spécification fonctionnelle dans notre cas se traduit par le diagramme des cas d’utili-
sation et la description textuelle.
3.3.1 Diagramme général de cas d’utilisation
Les diagrammes de cas d’utilisation sont des représentations graphiques couramment

utilisées en UML afin de fournir une vue d’ensemble du comportement fonctionnel d’un
système logiciel. Un cas d’utilisation décrit un ensemble d’actions séquentielles qu’un système
effectue pour produire un résultat observable par un acteur.
31
La figure 4.1 représente le diagramme de cas d’utilisation global relatif à notre application.
Figure 3.1 – Diagramme de cas d’utilisation global
32
3.3.2 Diagramme de classes
Le diagramme de classes offre une représentation statique de notre système, en spécifiant

toutes les classes et leurs relations pour identifier les entités qui modélisent notre application.
Les différentes classes persistantes de l’application sont :

• Classe Utilisateur : Elle représente toutes les informations concernant l’utilisateur.
• Classe Category : Elle représente toutes les informations concernant les categories.
• Classe Post : Elle représente toutes les informations concernant les publications.
• Classe Comment : Elle représente toutes les informations concernant les commen-
taires.
• Classe Training : Elle représente toutes les informations concernant les formations et
les workshops.
• Classe Challenge : Elle représente toutes les informations concernant les défis.
• Classe Tags : Elle représente toutes les informations concernant les tags.
• Classe Chatroom : Elle représente toutes les informations concernant les discussions.
• Classe Message : Elle représente toutes les informations concernant les messages.
• Classe Notification : Elle représente toutes les informations concernant les notifica-
tions.
33
La figure 3.2 représente notre diagramme de classes :
Figure 3.2 – Diagramme de classes
34
3.3.3 Diagramme de séquence
Les diagrammes de séquence sont des représentations graphiques des interactions entre
les acteurs et le système, organisées dans l’ordre chronologique selon la norme UML. Dans
cette section, nous présentons les diagrammes de séquence système des cas d’utilisation les
plus importants classifiés.
Diagramme de séquence "Authentification" :
Cas d’utilisation S’authentifier

Acteurs Administrateur
Pré condition L’administrateur doit avoir un compte valide dans le système
Scénario principal 1. L’administrateur envoie une requête d’authentification avec
les informations d’identification requises.
2. Le système vérifie les données d’identification entrées.
3. Si les données sont valides, le système génère un jeton d’au-
thentification (JWT) pour l’administrateur.
4. Le système renvoie le jeton d’authentification à l’administra-
teur.
5. L’administrateur utilise le jeton d’authentification pour accé-
der aux fonctionnalités réservées aux administrateurs.
Scénario Alternatif Jeton d’authentification invalide

3a. Le système vérifie les données d’identification entrées.
3b. Les données d’identification de l’administrateur sont incor-
rectes ou manquantes.
3c. Le système renvoie un message d’erreur indiquant des don-
nées d’identification invalides.
3d. L’administrateur doit se reconnecter en fournissant des in-
formations d’identification valides.
Post condition Administrateur authentifié
Table 3.2 – Description textuelle du cas d’utilisation «S’authentifier»
35
La figure 3.3 représente le diagramme de séquence de la phase "Authentification" :
Figure 3.3 – Diagramme de séquence "Authentification"
36
Diagramme de séquence "Ajouter utilisateur" :
Cas d’utilisation Ajouter utilisateur

Pré condition L’administrateur doit s’authentifier avant d’effectuer cette tâche.
Scénario principal 1. L’administrateur saisit les nouvelles données utilisateur.
2. Le système vérifie les données saisies.
3. L’utilisateur peut accéder à l’application.
Scénario Alternatif La séquence débute à partir du point 2 du scénario principal :

2a. Le système vérifie les données saisies.
2b. Message d’erreur : données manquantes / utilisateur déjà
existant.
2c. Reprise à partir du point 2.
Post condition L’utilisateur est créé avec succès.
37
La figure 3.4 représente notre diagramme de séquence de la phase "Ajouter Utilisateur" :
Figure 3.4 – Diagramme de séquence "Ajouter utilisateur"
38
3.4 Revue du sprint

L’objectif de la revue est de présenter les réalisations du sprint afin de déterminer les
implications pour la suite du projet.
La figure 3.5 ci-dessous illustre l’historique des demandes de fusion (Merge Requests) sur
GitLab.
Figure 3.5 – Historique des demandes de fusion (Merge Requests)
La figure 3.6 ci-dessous montre les premiers commits effectués, qui font partie de l’histo-
rique du développement de l’application.
Figure 3.6 – Historique des premiers commits effectués
39
La figure 3.7 ci-dessous montre le test d’autorisation avec JWT.
Figure 3.7 – Test d’autorisation avec JWT
La figure 3.8 ci-dessous illustre le test d’ajout d’un post.
Figure 3.8 – Test d’ajout d’un post
40
3.5 Rétrospective
Dans cette section, nous allons citer les rétrospectives dégagées par le PO, le bilan de ce
qui a marché, ce qui n’a pas marché et ce qui peut être amélioré.
Ce qui a été validé :
• Authentification et autorisation
• Gestion utilisateurs
• Gestion catégories
• Gestion publications
• Gestion defis
• Gestion formations
• Gestion workshops
• Gestion commentaires
• Gestion notifications
• Gestion chat
Ce qui n’a pas été validé :
• Rien
Ce qui doit être amélioré :
• Rien
Conclusion
À l’issue de ce chapitre, nous avons réussi à développer un incrément de grande valeur
qui peut être directement déployé en environnement de production. Par la suite, nous allons
introduire le deuxième sprint du front-end "côté administrateur".
41
Front-End "Administrateur"
4
Introduction
Ce sprint se concentre sur le développement du front-end côté administrateur de notre
application DIGISTACK. En mettant l’accent sur cette partie du système, nous visons à four-
nir aux administrateurs des fonctionnalités avancées et conviviales pour gérer efficacement
les utilisateurs, les autorisations et les paramètres de l’application. L’objectif est d’amélio-
rer l’expérience et la productivité des administrateurs en leur offrant un ensemble d’outils
puissants et intuitifs pour superviser et gérer le système de chat interne de manière efficace.
4.1 Objectif du Sprint

L’objectif de ce sprint est de mettre en place les maquettes pour optimiser la gestion des
fonctionnalités principales du système. Cela inclut l’authentification, l’autorisation, les opé-
rations CRUD de la gestion des utilisateurs, des catégories, des publications, des workshops,
des défis, du profil, des formations, des commentaires et des notifications. L’accent sera mis
sur la création d’une base solide pour ces fonctionnalités clés, garantissant leur efficacité et
leur intégration harmonieuse dans le système global.
42
Chapitre 4. Front-End "Administrateur"
4.2 Sprint Backlog

Le tableau 4.1 ci-dessous récapitule les différentes tâches à accomplir dans ce deuxième
sprint.

1 Implémentation des maquettes : 17
• Login page
• Home page
• Team page
• Challenge page
• Workshops page
• Tutorial page
• Category page
2 Intégration/Utilisation des APIs 11
43
4.3 Diagramme de cas d’utilisation

La figure 4.1 représente le diagramme de cas d’utilisation de ce deuxième sprint.
Figure 4.1 – Diagramme de cas d’utilisation pour l’Administrateur
44
4.4 Diagrammes de cas d’utilisation raffinés

Les figures ci-dessous représentent les diagrammes de cas d’utilisation raffinés, accom-
pagnés de leurs descriptions textuelles, afin de détailler les fonctionnalités du système. La
figure 4.2 présente le diagramme du cas d’utilisation "S’authentifier".
Figure 4.2 – Diagramme de cas d’utilisation s’authentifier
La figure 4.3 présente le diagramme du cas d’utilisation "Gérer les utilisateurs".
Figure 4.3 – Diagramme de cas d’utilisation «Gérer les utilisateurs»
45
Le tableau 4.2 représente la description textuelle du cas d’utilisation "Ajouter utilisa-

teur".
Cas d’utilisation Ajouter utilisateur

Acteur Administrateur
Pré-condition L’administrateur doit être authentifié dans le système
Scénario principal 1. L’administrateur accède à la page de gestion des utilisa-
teurs dans l’application.
2. Le système affiche la liste des utilisateurs existants.
3. L’administrateur a la possibilité d’ajouter un nouvel uti-
lisateur en remplissant un formulaire contenant les champs
"email" et "fullname".
4. Le système génère un mot de passe aléatoire pour le nouvel
utilisateur et effectue son cryptage.
5. Le système enregistre les informations de l’utilisateur, y
compris l’email et le mot de passe crypté.
6. Le système envoie un e-mail à l’utilisateur nouvellement
créé, contenant son email et son mot de passe pour accéder à
la plateforme.
Scénario alternatif 4a. Si les champs requis ne sont pas remplis lors de l’ajout
d’un nouvel utilisateur, le système affiche un message d’erreur
et demande à l’administrateur de les compléter.
4b. Si l’utilisateur déjà existant est détecté dans le système
lors de l’ajout d’un nouvel utilisateur, le système affiche un
message d’erreur indiquant que l’utilisateur existe déjà.
Post-condition Les informations de l’utilisateur nouvellement ajouté (email,
mot de passe crypté) sont enregistrées dans le système.
L’utilisateur reçoit un e-mail contenant ses informations de
connexion.
Table 4.2 – Description textuelle du cas d’utilisation "Ajouter utilisateur"
46
La figure 4.4 représente la description textuelle du cas d’utilisation "Gérer les publica-
tions".
Figure 4.4 – Diagramme de cas d’utilisation "Gérer les publications"
Le tableau 4.3 présente la description textuelle du cas d’utilisation "Gérer les publica-
tions".
47
Cas d’utilisa- Gérer les publications

tion
Acteur Administrateur
Scénario prin- 1. L’administrateur accède à la page de gestion des publications
cipal dans l’application.
2. Le système affiche la liste des publications existantes.
3. L’administrateur peut ajouter une nouvelle publication en rem-
plissant les informations requises (titre, description, catégorie, et
éventuellement code).
4. Le système enregistre la nouvelle publication dans la base de
données.
5. L’administrateur peut modifier une publication existante en sé-
lectionnant la publication et en modifiant les informations perti-
nentes.
6. Le système met à jour les informations de la publication modi-
fiée.
7. L’administrateur peut supprimer une publication existante en
sélectionnant la publication et en confirmant la suppression.
8. Le système supprime la publication de la base de données.
9. L’administrateur peut consulter une publication en sélectionnant
la publication dans la liste.
10. L’administrateur peut réagir à une publication en commentant
ou en votant (vote up ou vote down).
11. Si l’administrateur choisit de commenter la publication, il peut
ajouter, modifier ou supprimer son commentaire.
12. Si l’administrateur choisit de valider un commentaire sur sa
propre publication, le système marque le commentaire comme va-
lidé.
48
13. Si l’administrateur choisit de voter, le système enregistre le vote

de l’administrateur pour la publication.
14. L’administrateur peut rechercher des publications en utilisant
des tags ou des catégories comme critères de recherche.
15. Le système affiche les résultats de la recherche correspondant
aux critères spécifiés par l’administrateur.
Scénario alter- 3a. Si les champs requis ne sont pas remplis lors de l’ajout d’une
natif nouvelle publication, le système affiche un message d’erreur indi-
quant les champs manquants et demande à l’administrateur de les
compléter.
3b. Si une publication avec le même titre existe déjà, le système
affiche un message d’erreur indiquant que le titre est déjà utilisé et
demande à l’administrateur de choisir un titre différent.
Post- Les modifications apportées aux publications sont enregistrées et re-
condition flétées dans la base de données du système. Les publications peuvent
être consultées, recherchées et affichées conformément aux critères
spécifiés par l’administrateur.
Table 4.3 – Description textuelle du cas d’utilisation "Gérer les publications"
La figure 4.5 représente le diagramme du cas d’utilisation "Gérer les catégories".
Figure 4.5 – Diagramme de cas d’utilisation "Gérer les categories"
49
Le tableau 4.4 présente la description textuelle du cas d’utilisation "Gérer les categories".
Cas d’utilisation Gérer les categories

acteurs Administrateur
Scénario principal 1. L’administrateur accède à la page de gestion des catégories
dans l’application.
2. Le système affiche la liste des catégories existantes.
3. L’administrateur a la possibilité d’ajouter une nouvelle ca-
tégorie en fournissant le nom de catégorie.
4. Le système vérifie que le champ requis est rempli et ajoute
la nouvelle catégorie à la liste.
5. L’administrateur peut modifier le nom d’une catégorie exis-
tante en sélectionnant la catégorie et en modifiant le champ
correspondant.
6. Le système met à jour le nom de la catégorie modifiée.
7. L’administrateur peut supprimer une catégorie existante
en sélectionnant la catégorie et en confirmant la suppression.
8. Le système supprime la catégorie de la liste.
Scénario alternatif 3a. Si le champ requis n’est pas rempli lors de l’ajout d’une
nouvelle catégorie, le système affiche un message d’erreur et
demande à l’administrateur de les compléter.
Post-condition Les modifications apportées aux catégories (ajout, modifica-
tion, suppression) sont enregistrées et visibles dans le système.
Table 4.4 – Description textuelle du cas d’utilisation "Gérer les categories"
50
4.5 Diagramme de séquences
4.5.1 Diagramme de séquence « Authentification »
La figure 4.6 représente la phase d’authentification de l’administrateur.
Figure 4.6 – Diagramme de séquence «Authentification»
51
4.5.2 Diagramme de séquence « Ajouter utilisateur »
La figure 4.7 ci-dessous montre l’interaction entre l’administrateur et les différentes in-
terfaces pour ajouter un nouvel utilisateur.
Figure 4.7 – Diagramme de séquence «Ajouter utilisateur»
52
4.5.3 Diagramme de séquence « Ajouter catégorie »
terfaces pour ajouter un nouvelle categorie.
Figure 4.8 – Diagramme de séquence «Ajouter catégorie»
53
4.5.4 Diagramme de séquence « Ajouter publication »
terfaces pour ajouter une publication.
Figure 4.9 – Diagramme de séquence «Ajouter publication»
54
4.6 Revue du sprint

La figure 4.10 représente l’interface de la page de login.
Figure 4.10 – Page login
La figure 4.11 représente l’interface de la page d’accueil.
Figure 4.11 – Page d’accueil «Admin»
55
La figure 4.12 représente l’interface de la page de gestion des utilisateurs.
Figure 4.12 – Page de gestion des utilisateurs «Admin»
La figure 4.13 représente l’interface de la page de gestion des challenges.
Figure 4.13 – Page de gestion des challenges «Admin»
56
La figure 4.14 représente l’interface de la page de gestion des workshops.
Figure 4.14 – Page de gestion des workshops «Admin»
La figure 4.15 représente l’interface de la page de gestion des formations.
Figure 4.15 – Page de gestion des formations «Admin»
57
4.7 Rétrospective
• Implémentation des maquettes (Pages : Login, Home, team, Challenge, Workshops,
Tutorial, Category)
• Les Operations CRUD : (Login, Post, Team, Challenge, Workshops, Tutorial, Cate-
gory)
• Implémentation des maquettes (Notification/Discussions/Profil)
• CRUD (Notification/Discussions/Profil)
• Rien
Conclusion
Ce chapitre a été consacré à la réalisation de la deuxième partie de notre application
visant à développer la partie front-end "côté administrateur". Dans la suite, nous présentons
la troisième partie pour développer la partie front-end "côté client".
58
Front-End "Utilisateur"
5
Introduction
Ce chapitre présente le troisième sprint du projet, qui se concentre sur l’implémentation
des maquettes (côté utilisateur) pour la gestion des publications, des workshops, des défis,
du profil, des formations, des commentaires et des notifications. Le sprint comprend une
phase d’analyse, de conception et de réalisation.
5.1 Objectif du Sprint

L’objectif de ce sprint est de de mettre en place les maquettes pour optimiser la gestion
des fonctionnalités principales du système du coté utilisateur. Cela inclut la gestion des
publications, des workshops, des défis, du profil, des formations, des commentaires et des
notifications.
59
Chapitre 5. Front-End "Utilisateur"
5.2 Sprint Backlog

Le tableau 5.1 ci-dessous récapitule les différentes tâches à accomplir dans le troisième
sprint.

1 Implémentation des maquettes : 17
• Home page
• Challenge page
• Publication page
• Team page
• Profile page
2 Intégration/Utilisation des APIs 11
5.3 Diagramme de cas d’utilisation

La figure 5.1 représente le diagramme de cas d’utilisation du deuxième sprint :
60
Figure 5.1 – Diagramme de cas d’utilisation «Utilisateur»
5.4 Diagrammes de cas d’utilisation raffinés

Les figures ci-dessous représentent les diagrammes de cas d’utilisation raffinés, accompa-
gnés de leurs descriptions textuelles, afin de détailler les fonctionnalités du système.
61
La figure 5.2 représente le diagramme du cas d’utilisation "Gérer les publications".
Figure 5.2 – Diagramme de cas d’utilisation "Gérer les publications"
62
La description textuelle du cas d’utilisation "Gérer les notification" est présentée dans le
tableau suivant :
Cas d’utilisa- Gérer les notification

tion
Acteur Utilisateur
Pré-condition L’utilisateur doit être authentifié dans le système
Scénario prin- 1. L’utilisateur clique sur l’icône de notification dans la barre de
cipal navigation de l’application.
2. Le système affiche la liste des notifications disponibles pour l’uti-
lisateur.
3. L’utilisateur peut consulter le contenu d’une notification en sé-
lectionnant la notification dans la liste.
4. L’utilisateur peut marquer une notification comme lue après
l’avoir consultée.
5. L’utilisateur peut supprimer une notification en sélectionnant la
notification et en confirmant la suppression.
Scénario alter- Aucun scénario alternatif pour ce cas d’utilisation.
natif
Post- Les notifications lues sont marquées comme lues dans le système et
condition les notifications supprimées sont retirées de la liste des notifications
de l’utilisation.
Table 5.2 – Description textuelle du cas d’utilisation «Gérer les notification»
Le diagramme de cas d’utilisation du cas "Consulter les défis" est modélisé à travers la
figure 5.3, et sa description textuelle est présentée dans le tableau 5.3.
63
Figure 5.3 – Diagramme de cas d’utilisation "Consulter les défis"
Cas d’utilisation Consulter les défis

Acteur Utilisateur
Pré-condition L’utilisateur doit être authentifié dans le système
Scénario princi- 1. L’utilisateur accède à la page de challenge dans l’application.
pal 2. Le système affiche la liste des défis disponibles.
3. L’utilisateur peut choisir un défi et accéder à ses détails.
4. Le système affiche les questions du défi sous forme de QCM
(Question à Choix Multiple).
5. L’utilisateur répond aux questions en sélectionnant les options
appropriées.
6. Une fois que l’utilisateur a terminé de répondre à toutes les
questions, le système calcule le nombre de points gagnés en fonction
des réponses correctes.
7. Le système met à jour le score de l’utilisateur en ajoutant les
points gagnés au score actuel.
8. Le système affiche le nombre de points gagnés et le nouveau score
de l’utilisateur.
64
Scénario alterna- 4a. Si l’utilisateur a déjà participé au défi sélectionné, le système

tif affiche un message indiquant que l’utilisateur ne peut pas participer
à nouveau.
Post-condition Le système enregistre les réponses de l’utilisateur, met à jour son
score et affiche les informations pertinentes.
Table 5.3 – Description textuelle du cas d’utilisation "Consulter les défis"
5.5 Diagramme de séquences
5.5.1 Diagramme de séquence « Ajouter publication »
La figure 5.4 ci-dessous montre l’interaction entre l’utilisateur et les différentes interfaces
pour ajouter une publication.
Figure 5.4 – Diagramme de séquence «Ajouter publication»
65
5.5.2 Diagramme de séquence « Supprimer publication »
pour supprimer une publication.
Figure 5.5 – Diagramme de séquence «Supprimer publication»
66
5.5.3 Diagramme de séquence « Modifier publication »
pour modifier une publication.
Figure 5.6 – Diagramme de séquence «Modifier publication»
67
5.5.4 Diagramme de séquence « Voter »
pour Voter une publication.
Figure 5.7 – Diagramme de séquence «Voter»
5.6 Revue du sprint
68
La figure 5.8 représente l’interface de la page d’accueil.
Figure 5.8 – Page d’accueil «User»
La figure 5.9 représente l’interface de la page de profil.
Figure 5.9 – Page de profil «User»
69
La figure 5.10 représente l’interface de la page de challenge.
Figure 5.10 – Page de challenge «User»
La figure 5.11 représente l’interface de la page de publication.
Figure 5.11 – Page de publication «User»
70
La figure 5.12 représente l’interface de la page des membres.
Figure 5.12 – Page des membres «User»
Les figures 5.13 et 5.14 représentent les interfaces de la page des avatars.
Figure 5.13 – Page des avatars Figure 5.14 – Page des avatars (femmes)
(hommes) «Utilisateur» «Utilisateur»
71
5.7 Rétrospective
• Implémentation des maquettes (Home, Challenge, Publication, Team, Profile)
• Les Operations CRUD : (Post,Comment,Profil)
• Implémentation des maquettes (Notification, Discussions)
• CRUD (Notification, Discussions)
• Rien
Conclusion
Au cours de ce cinquième chapitre, nous avons présenté le troisième sprint. À cette étape,
nous avons donc réussi à développer la partie frontend de notre application côté utilisateur.
72
Intégration d’un Système de Recommandation
6
basé sur l’API OpenAI
Introduction
L’intégration d’un système de recommandation efficace est essentielle pour améliorer
l’expérience des utilisateurs dans les applications web interactives. Notre objectif principal
dans ce sprint est d’intégrer un système de recommandation basé sur l’API OpenAI. Ce
système permettra de fournir aux utilisateurs des réponses pertinentes et personnalisées à
leurs questions et contribuera ainsi à améliorer la qualité de l’interaction sur la plateforme.
6.1 Objectif du sprint

L’objectif de ce sprint est de développer et d’intégrer un système de recommandation
dans notre application web. Ce système utilisera des techniques avancées de traitement du
langage naturel pour analyser les questions des utilisateurs et leur fournir des suggestions de
réponses pertinentes provenant de la base de connaissances de la plateforme.
73
Chapitre 6. Intégration d’un Système de Recommandation basé sur l’API OpenAI
6.2 Backlog du sprint

Le tableau 6.1 ci-dessous récapitule les différentes tâches à accomplir dans le quatrième
sprint :

1 25
• Etude théorique des systèmes de recommanda-
tion
• Choix, intégration, utilisation et test d’un sys-
tème de recommandation
6.3 Système de recommandation : Définition et avan-

tages
Un système de recommandation est un mécanisme qui analyse les données utilisateur et
les modèles de comportement pour fournir des suggestions personnalisées. Dans notre cas, il
s’agit d’un système qui analyse les questions posées par les utilisateurs de notre application et
génère des recommandations de réponses basées sur le contenu de notre base de connaissances
[12].
L’intégration d’un système de recomandation dans DIGISTACK nous permettra d’avoir
plusieurs avantages, parmi lesquels nous pouvons citer :
• L’amélioration de l’expérience utilisateur : Un système de recommandation peut aider
les utilisateurs de notre application à trouver rapidement et efficacement les infor-
mations ou les ressources dont ils ont besoin. Cela facilite la navigation et permet
d’accéder rapidement aux contenus pertinents, ce qui améliore l’expérience globale de
l’utilisateur.
• La personnalisation du contenu : Grâce à un système de recommandation, DIGIS-
TACK peut fournir des recommandations personnalisées en fonction des préférences
et des comportements de chaque utilisateur. Cela permet de proposer du contenu
74
pertinent et adapté à leurs besoins spécifiques, ce qui renforce l’engagement et la

satisfaction des utilisateurs.
• Augmentation de la productivité : En suggérant automatiquement des réponses, des
documents ou des ressources pertinents lors des conversations, un système de recom-
mandation peut aider les utilisateurs de DIGISTACK à gagner du temps et à être
plus efficaces dans leurs tâches quotidiennes. Cela favorise une meilleure productivité
au sein de l’organisation.
• Découverte de nouvelles informations : Un système de recommandation peut égale-
ment aider les utilisateurs de notre application à découvrir de nouvelles informations,
documents ou collègues avec lesquels ils pourraient interagir. Cela favorise l’appren-
tissage continu, l’échange de connaissances et la collaboration au sein de l’entreprise.
• Optimisation des processus internes : En recommandant des actions ou des étapes spé-
cifiques à suivre dans les conversations, un système de recommandation peut contri-
buer à l’automatisation et à l’optimisation des processus internes dans l’entreprise.
Cela permet d’accélérer les flux de travail et de garantir la cohérence dans les inter-
actions entre les employés de DIGISTACK.
6.4 Etude théorique des modèles d’OpenAI

Dans cette section, nous allons présenter une étude théoprique des modèles d’openAI afin
de choisir le modèle adéquat à intégrer et à utiliser dans notre application.
6.4.1 Présentation des modèles d’openAI
L’introduction des modèles d’OpenAI a marqué une avancée majeure dans le domaine de
l’intelligence artificielle et du traitement du langage naturel. Ces modèles, tels que GPT-3
(Generative Pre-trained Transformer 3), ont démontré une remarquable capacité à com-
prendre, générer et interagir avec le langage humain. Ils sont entraînés sur d’énormes quan-
tités de données textuelles provenant de diverses sources, leur permettant d’acquérir une
connaissance approfondie et une maîtrise du langage.[3]
Le tableau 6.2 présente une liste non exhaustive des modèles de l’openIA courament
utilisés, avec leurs domaines d’application, leurs opérations par minute (TPM), et leurs
75
requêtes par minute (RPM).
Nom du modèle Domaine d’ap- Opérations par mi- Requêtes par mi-
plication du nute (TPM) nute (RPM)
modèle
gpt-3.5-turbo CHAT 60 40 000
gpt-3.5-turbo-16k CHAT 60 150 000
babbage TEXT 60 150 000
davinci TEXT 60 150 000
text-babbage-001 TEXT 60 150 000
text-curie-001 TEXT 60 150 000
text-davinci-003 TEXT 60 150 000
text-davinci-edit-001 TEXT 20 150 000
whisper-1 AUDIO 50 150 000
Table 6.2 – Liste de de quelques modèles existants d’openAI [3]
6.4.2 Etude comparative entre les modèles d’openAI
La comparaison entre les modèles d’OpenAI constitue une étape essentielle de notre
étude, afin de choisir un modèle performant pour DIGISTACK. Nous nous appuierons sur
une évaluation rigoureuse des performances, de la génération de texte et de la pertinence des
recommandations offertes par ces modèles, afin de déterminer celui qui convient le mieux à
notre système de recommandation basé sur OpenAI. Pour cela, nous allons considérer les 3
critères suivants afin de choisir le modèle adéquat à utiliser dans notre application :
• Le temps de réponse : qui mesure le temps nécessaire pour générer des recommanda-
tions à partir de l’API,
• La qualité de réponse : qui fait référence à la mesure dans laquelle les recommandations
fournies par le système sont pertinentes, précises et utiles pour les utilisateurs.
• La scalabilité : qui évalue la capacité du système à gérer une charge de demande
croissante sans dégradation significative des performances.
Le tableau 6.3 résume l’étude comparative entre les modèles choisis en fonction des critères
cités.
76
Modèle Temps de réponse Qualité de réponse Nombre de Scalabilité

paramètres
Babbage <1s Moyenne 1,4 milliard Bonne
Curie 1s < t < 2s Bonne 13 milliards Très bonne
Davinci >2s Très bonne 175 milliards Très bonne
Table 6.3 – Etudes comparative entre les différentes modèles testés [3]
6.4.3 Choix du modèle openAI à adopter
Le choix du modèle OpenAI à adopter pour notre système de recommandation repose

sur un équilibre entre plusieurs critères clés : le temps de réponse, la qualité de réponse et
la scalabilité. Bien que la qualité de réponse soit une considération essentielle, nous devons
également prendre en compte la nécessité de répondre rapidement aux demandes des utili-
sateurs et de maintenir une bonne scalabilité du système. En effet, il est crucial que notre
système puisse générer des recommandations dans des délais acceptables, afin de garantir
une expérience utilisateur fluide et réactive. De plus, la scalabilité est un aspect crucial, car
notre système doit être capable de gérer une charge croissante d’utilisateurs et de maintenir
de bonnes performances même avec une augmentation du volume de données.
Il est également primordial de souligner l’importance de laisser de l’espace aux utilisateurs
de la plateforme de pour interagir entre eux. En effet, bien que le système de recomman-
dation puisse fournir des suggestions et des conseils pertinents, il est essentiel de favoriser
les échanges directs et la collaboration entre les utilisateurs. En permettant aux utilisateurs
d’explorer, de partager et de discuter activement pour encourager la créativité, les échanges
d’idées et les synergies au sein de l’entreprise. Le système de recommandation doit donc être
conçu de manière à compléter et à enrichir les interactions entre les utilisateurs, tout en
respectant leur autonomie et en leur offrant la possibilité d’interagir librement pour résoudre
des problèmes, partager des connaissances et établir des relations professionnelles solides.
En considérant tout ces critères, nous avons opté pour l’utilisation du modèle text-
davinci-003.
77
6.5 Etude pratique : utilisation et intégration de l’API

text-davinci-003 dans DIGISTACK
Dans le cadre de notre étude pratique, nous nous concentrerons sur l’intégration et l’uti-
lisation du modèle text-davinci-003 dans notre système. L’objectif principal de cette étude
est de démontrer comment ce modèle OpenAI peut être efficacement exploité pour générer
des recommandations de haute qualité dans notre application.
6.5.1 Workflow d’échange entre DIGISTACK et OpenAI
terfaces pour publier une publication.
Figure 6.1 – Diagramme de séquence "ajouter publication" avec OpenAI
Ce diagramme de séquence pour l’ajout de publication offre une représentation visuelle

des interactions entre l’administrateur de l’application et le modèle OpenAI dans le contexte
78
de l’ajout d’une publication. Ce diagramme met en évidence le processus étape par étape,
depuis la saisie des informations de la publication par l’administrateur jusqu’à la génération
d’une recommandation par le modèle OpenAI.
6.5.2 Configuration, mise en place et intégration du modèle OpenAI
Le code illustré dans la figure 6.2 met l’accent sur l’implémentation de la fonction "ge-
nerateChatgptResponse", qui envoie une question à l’API OpenAI et renvoie la réponse
générée.
Cette fonction envoie la question à l’API OpenAI, qui génère une réponse basée sur le mo-
dèle spécifié. La réponse est ensuite renvoyée à l’utilisateur. Cela améliore significativement
la qualité de l’interaction sur notre plateforme."
Figure 6.2 – Fonction "generateChatgptResponse"
Voici une explication des paramètres de cette fonction :

• Modèle : le modèle est la spécification de l’architecture et des paramètres utilisés par
OpenAI pour générer des réponses. Chaque modèle a ses propres caractéristiques et
capacités.
• Prompt : le prompt fait référence au texte d’entrée ou à la question fournie au modèle
pour générer une réponse. Il fournit le contexte ou les instructions nécessaires au
79
modèle pour produire une sortie pertinente.

• n : Le paramètre "n" indique le nombre de réponses que le modèle doit générer. Par
exemple, si "n" est égal à 1, le modèle générera une seule réponse.
• max_tokens : le paramètre "max_tokens" spécifie le nombre maximum de jetons
(mots et ponctuation) que le modèle doit générer dans sa réponse. Cela permet de
contrôler la longueur de la sortie générée.
• stop :le paramètre "stop" est une chaîne de caractères ou un tableau de chaînes utilisé
par le modèle pour déterminer quand arrêter la génération de texte. Lorsque le modèle
rencontre l’une de ces chaînes, il cesse de générer du texte.
• temperature : la température est un paramètre qui contrôle la créativité des réponses
générées par le modèle. Une valeur plus élevée de température produira des réponses
plus diversifiées, tandis qu’une valeur plus faible donnera des réponses plus conserva-
trices et prévisible.
6.5.3 Evaluation du modèle utilisé
L’évaluation de l’API utilisée par les utilisateurs de notre application dans la société a
été réalisée avec rigueur en tenant compte des critères essentiels tels que le temps de réponse,
la pertinence des réponses et la scalabilité. Chaque utilisateur a été invité à attribuer une
note allant de 1 à 5 pour notre système de recommandation qui utilise l’OpenAI. Ces notes
ont ensuite été analysées et une moyenne a été calculée pour chaque critère.
Les résultats de l’évaluation sont extrêmement satisfaisants, dépassant largement la moyenne
pour les trois critères évalués. En ce qui concerne le temps de réponse, les utilisateurs ont
constaté une grande réactivité de notre système, permettant d’obtenir des réponses presque
instantanées à leurs requêtes. En termes de pertinence des réponses, le système de recomman-
dation a su proposer des suggestions précises et adaptées aux besoins spécifiques de chaque
utilisateur. Enfin, en ce qui concerne la scalabilité, le système a pu gérer efficacement une
augmentation du nombre d’utilisateurs et de demandes sans compromettre ses performances.
Ces résultats témoignent de l’efficacité et de la fiabilité de notre système de recommanda-
tion basé sur l’OpenAI. L’évaluation réalisée par les utilisateurs démontre la valeur ajoutée
que notre application apporte en termes de qualité des recommandations et de réactivité.
80
6.6 Revue du sprint

Les figures 6.3 et 6.4 représentent des exemples de réponses générées par la fonction
"generateChatgptResponse" :
Figure 6.3 – Exemple 1 de réponse générée par la fonction "generateChatgptResponse"
Figure 6.4 – Exemple 2 de réponse générée par la fonction "generateChatgptResponse"
81
6.7 Rétrospective
• Integration du système de recommandation
• Test du système avec Postman
• Integration du système dans la partie frontend
• Rien
Conclusion
Dans ce sprint, nous avons intégré avec succès un système de recommandation basé sur
l’API OpenAI dans notre application web. Ce système offre des recommandations pertinentes
et personnalisées aux utilisateurs, améliorant ainsi leur expérience et leur engagement sur la
plateforme. Nous avons également sélectionné l’API OpenAI la plus adaptée à nos besoins,
en utilisant une approche de recommandation qui répond efficacement aux besoins de notre
application.
82
Conclusion Générale
Ce document a été rédigé en termes de notre projet de fin d’études au sein de la société
DIGINOV en vue de l’obtention du diplôme d’ingénieur en Génie Informatique de l’École
Polytechnique Sousse.
Le travail réalisé lors de ce projet s’est concentré sur la conception et la mise en œuvre
d’une application web afin de permettre à tous les membres de l’équipe DIGINOV de parta-
ger et d’enrichir leurs connaissances techniques et de faire de la veille technologique. La mise
en œuvre de notre projet s’est déroulée en plusieurs étapes. Une première étape a consisté à
comprendre le contexte général du projet. Une deuxième étape a visé à analyser et mettre
en évidence les besoins réels de l’utilisateur. Cette étape est l’une des étapes clés dans le
succès de tout projet. C’est pour cette raison que nous avons consacré une période impor-
tante à l’analyse et à la spécification des besoins. Nous avons opté pour la méthode Scrum
comme processus de développement et pour UML comme langage de modélisation. Pour la
réalisation, nous avons utilisé un ensemble varié d’outils.
Bien que nous ayons rencontré quelques difficultés au début du projet, cela a été une
bonne occasion de sortir du cadre théorique et d’appliquer les connaissances acquises lors
des études universitaires dans le monde du travail. De plus, ce projet nous a permis de mettre
en pratique les connaissances acquises concernant le cycle de vie d’un projet informatique.
Cette réalisation a également été l’occasion d’intégrer le monde professionnel et d’apprendre
plusieurs compétences et habitudes liées aux problématiques sociales telles que le travail en
groupe et la collecte d’informations, dans le but d’extraire les besoins des acteurs du système
à mettre en œuvre. Ce projet est un noyau sur lequel plusieurs perspectives peuvent être
développées et enrichies. En effet, le travail que nous avons réalisé est modulaire et évolutif.
En termes de perspectives, nous pouvons distinguer plusieurs améliorations pour notre
projet. Nous proposons d’ :
• Intégrer un système de récompenses basé sur le score de l’utilisateur.
• Intégrer un système de réunion.
À la fin, nous souhaitons que ce modeste travail apporte progrès, évolution et satisfaction
83
Conclusion Générale
aux responsables de DIGINOV, aux membres de Jury et aux personnes intéressé par la mise
en place d’une telle solution.
84
Bibliographie
[1] A Comprehensive Guide to Web Application Architecture. https://www.

netsolutions.com/insights/web-application-architecture-guide/. [Consulter
le 10 mars].
[2] MEAN Stack vs. MERN Stack : A Comprehensive Comparison. https://www.

tatvasoft.com/blog/mean-stack-vs-mern-stack/. [Consulter le 12 mars].
[3] Documentation OpenAI. https://platform.openai.com/docs/introduction.

[Consulter le 02 juin].
[4] DIGINOV Tunisia LinkedIn. https://www.linkedin.com/company/diginovtunisie/

mycompany/. [Consulté le 9 mars].
[5] Microsoft Teams : Avantages et inconvénients. https://www.aurelium.be/fr/blog/

microsoft-teams-avantages-inconvenients. [Consulter le 9 mars].
[6] Skype : Avantages et inconvénients. https://www.online-sciences.com/

technology/what-are-the-advantages-and-disadvantages-of-skype/. [Consulté
le 9 mars].
[7] What Is Agile Methodology in Project Management ?

https://www.wrike.com/project-management-guide/faq/
what-is-agile-methodology-in-project-management/. [Consulté le 9 mars].
[8] Comprendre la méthode Agile Scrum en 10 minutes. https://www.tuleap.org/fr/

agile/comprendre-methode-agile-scrum-10-minutes. [Consulté le 9 mars].
[9] What Is Scrum ? https://resources.collab.net/agile-101/what-is-scrum.

[Consulté le 9 mars].
[10] Why Your Application Should Be Built with a Component-

Based Architecture in Mendix. https://www.prolim.com/
85
Bibliographie
why-your-application-should-be-built-with-a-component-based-architecture-in-mendi
[Consulter le 12 mars].
[11] Component-Based Architecture. https://www.tutorialspoint.com/software_

architecture_design/component_based_architecture.htm. [Consulter le 12 mars].
[12] Elsa Negre. Vers une typologie de contexte pour les systèmes de recommandation. In
INFORSID, pages 197–212, 2018.
86
Annexe
Chapitre 2
Diagramme de contexte
Le diagramme de contexte est un type de diagramme UML qui représente les interactions
entre un système et son environnement externe, sous la forme d’une "Black-Box", ainsi que
les acteurs qui interagissent avec le système à travers les liens et les cardinalités, comme le
montre la figure suivante :
Figure 6.5 – Diagramme de contexte
Etablissement de la définition de "Done"

La Définition de Done (DoD) permet de connaître le travail attendu par l’ensemble de
l’équipe (Scrum Master, Product Owner, toute l’équipe de développement). Elle garantit la
transparence et la qualité du produit. Dans ce projet, nous avons démontré que la Définition
de Done apporte une aide précieuse, tant pour le Scrum Master que pour le Product Owner.
La figure 6.6 ci-dessus montre la planification du travail à l’aide de l’outil Trello :
87
Annexe
Figure 6.6 – Planification des sprints avec Trello
88
Annexe
Systèmes de contrôle de version avec GitLab

Le contrôle de version est une composante essentielle de notre processus de développement,
permettant de gérer efficacement les différentes versions de notre code source. Nous avons
choisi d’utiliser GitLab comme plateforme de contrôle de version. Pour organiser notre flux de
travail, nous avons utilisé une approche de gestion de branches avec GitLab. Nous avons créé
une branche "dev" à partir de la branche principale (main) pour permettre le développement
itératif et incrémental. Cela nous a permis de travailler sur de nouvelles fonctionnalités de
manière isolée, tout en maintenant la stabilité de la branche principale. Les merge requests
de GitLab ont été utilisés pour faciliter la revue du code et l’approbation des modifications
avant leur intégration dans la branche principale. La figure 6.7 présente la branche "dev"
utilisées dans notre projet.
Figure 6.7 – branches Gitlab
En utilisant GitLab comme système de contrôle de version, nous avons pu bénéficier de

fonctionnalités avancées telles que la gestion des branches, la collaboration efficace, la traça-
bilité des modifications et la gestion des conflits. Cela a contribué à assurer un développement
fluide et une gestion efficace du code source tout au long du projet.
89
Annexe
Chapitre 4
Diagramme de cas d’utilisation affiné :
Diagramme de cas d’utilisation affiné «Gérer le profil» :
Figure 6.8 – Diagramme de cas d’utilisation affiné «Gérer le profil»
90
Annexe
Diagramme de cas d’utilisation affiné «Gérer les workshops» :
Figure 6.9 – Diagramme de cas d’utilisation affiné «Gérer les workshops»
Diagramme de cas d’utilisation affiné «Gérer les défis» :
Figure 6.10 – Diagramme de cas d’utilisation affiné «Gérer les défis»
91
Annexe
Diagramme de cas d’utilisation affiné «Gérer les formations» :
Figure 6.11 – Diagramme de cas d’utilisation affiné «Gérer les formations»
Diagramme de cas d’utilisation affiné «Gérer les notifications» :
Figure 6.12 – Diagramme de cas d’utilisation affiné «Gérer les notifications»
92
Annexe
Diagramme de cas d’utilisation affiné «Gérer les discussions» :
Figure 6.13 – Diagramme de cas d’utilisation affiné «Gérer les discussions»
93
Annexe
Description textuelle
Description textuelle du cas d’utilisation «S’authentifier» :
Cas d’utilisation S’authentifier

Pré condition L’administrateur doit avoir un compte valide dans le système
Scénario principal 1. L’administrateur accède à la page de connexion de l’applica-
tion.
2. Le système affiche le formulaire de connexion, demandant à
l’administrateur de saisir son email et son mot de passe.
3. L’administrateur saisit son email et son mot de passe.
4. Le système vérifie les informations d’identification fournies
par l’administrateur.
5. Si les informations sont valides, le système authentifie l’ad-
ministrateur et lui accorde l’accès aux fonctionnalités réservées
aux administrateurs.
6. Le système affiche le tableau de bord de l’administrateur.
Scénario Alternatif 4a. Si les informations d’identification fournies par l’administra-
teur sont incorrectes, le système affiche un message d’erreur et
l’administrateur reste sur la page de connexion. L’administra-
teur peut réessayer de saisir ses informations d’identification.
Post condition Administrateur authentifié
94
Annexe
Description textuelle du cas d’utilisation «Gérer les workshops» :
Cas d’utilisation Gérer les workshops

Pré condition L’administrateur doit être authentifié dans le système
Scénario principal 1. L’administrateur accède à la page de gestion des workshops
dans l’application.
2. Le système affiche la liste des workshops existants.
3. L’administrateur peut ajouter un nouveau workshop en rem-
plissant les informations requises, telles que le titre, la descrip-
tion, la date, etc.
4. Le système enregistre le nouveau workshop dans la base de
données.
5. L’administrateur peut modifier un workshop existant en sé-
lectionnant le workshop et en modifiant les informations perti-
nentes.
6. Le système met à jour les informations du workshop modifié.
7. L’administrateur peut supprimer un workshop existant en sé-
lectionnant le workshop et en confirmant la suppression.
8. Le système supprime le workshop de la base de données.
Scénario Alternatif 3a. Si les champs requis ne sont pas remplis lors de l’ajout d’un
nouveau workshop, le système affiche un message d’erreur indi-
quant les champs manquants et demande à l’administrateur de
les compléter.
3b. Si un workshop avec le même titre existe déjà, le système
affiche un message d’erreur indiquant que le titre est déjà utilisé
et demande à l’administrateur de choisir un titre différent.
Post condition Les modifications apportées aux workshops sont enregistrées et
reflétées dans la base de données du système.
Table 6.5 – Description textuelle du cas d’utilisation «Gérer les workshops»
95
Annexe
Description textuelle du cas d’utilisation «Gérer les défis» :
Cas d’utilisation Gérer les défis

Scénario principal 1. L’administrateur accède à la page de gestion des défis dans
l’application.
2. Le système affiche la liste des défis existants.
3. L’administrateur peut ajouter un nouveau défi en remplis-
sant les informations requises, telles que le titre, la description,
le bonus et les questions avec leurs réponses.
4. Le système enregistre le nouveau défi dans la base de don-
nées.
5. L’administrateur peut modifier un défi existant en sélec-
tionnant le défi et en modifiant les informations pertinentes.
6. Le système met à jour les informations du défi modifié.
7. L’administrateur peut supprimer un défi existant en sélec-
tionnant le défi et en confirmant la suppression.
8. Le système supprime le défi de la base de données.
9. L’administrateur peut activer un défi en le sélectionnant et
en confirmant l’activation.
Scénario Alternatif 3a. Si les champs requis ne sont pas remplis lors de l’ajout
d’un nouveau défi, le système affiche un message d’erreur in-
diquant les champs manquants.
9a. Si un défi est déjà activé, le système affiche un message
d’erreur indiquant qu’un autre défi est déjà actif.
Post condition Les modifications apportées aux défis sont enregistrées et re-
flétées dans la base de données du système.
Table 6.6 – Description textuelle du cas d’utilisation «Gérer les défis»
Description textuelle du cas d’utilisation «Gérer le profil» :
96
Annexe
Cas d’utilisa- Gérer le profil

tion
Scénario prin- 1. L’administrateur accède à la page de gestion de son profil dans l’ap-
cipal plication.
2. Le système affiche les informations actuelles du profil de l’adminis-
trateur, telles que le nom, l’email et l’avatar.
3. L’administrateur peut modifier son nom en saisissant un nouveau
nom dans le champ correspondant.
4. Le système met à jour le nom de l’administrateur dans la base de
données.
5. L’administrateur peut modifier son email en saisissant une nouvelle
adresse email dans le champ correspondant.
6. Le système met à jour l’email de l’administrateur dans la base de
données.
7. L’administrateur peut modifier son mot de passe en saisissant un
nouveau mot de passe dans le champ correspondant.
8. Le système vérifie la conformité des critères de sécurité du mot de
passe, le crypte à l’aide d’un algorithme de cryptage sécurisé, puis met
à jour le mot de passe de l’administrateur dans la base de données.
9. L’administrateur peut modifier l’avatar en sélectionnant une avatar
de la liste.
10. Le système enregistre le nom de l’avatar de l’administrateur dans
la base de données.
Scénario Al- 5a. Si l’adresse email est déjà utilisée par un autre compte, le système
ternatif affiche un message d’erreur indiquant que l’email est déjà enregistré
et demande à l’administrateur de choisir une autre adresse email.
Post condition Les modifications apportées au profil de l’administrateur sont enregis-
trées et reflétées dans la base de données du système.
Table 6.7 – Description textuelle du cas d’utilisation «Gérer le profil»
97
Annexe
Description textuelle du cas d’utilisation «Gérer les formations» :
Cas d’utilisa- Gérer les formations

tion
Scénario prin- 1. L’administrateur accède à la page de gestion des formations dans
cipal l’application.
2. Le système affiche la liste des formations existantes.
3. L’administrateur peut ajouter une nouvelle formation en rem-
plissant les informations requises (titre, description, link).
4. Le système enregistre la nouvelle formation dans la base de don-
nées.
5. L’administrateur peut modifier une formation existante en sélec-
tionnant la formation et en modifiant les informations pertinentes.
6. Le système met à jour les informations de la formation modifiée.
7. L’administrateur peut supprimer une formation existante en sé-
lectionnant la formation et en confirmant la suppression.
8. Le système supprime la formation de la base de données.
Scénario Al- 3a. Si les champs requis ne sont pas remplis lors de l’ajout d’une
ternatif nouvelle formation, le système affiche un message d’erreur indiquant
les champs manquants et demande à l’administrateur de les com-
pléter.
3b. Si une formation avec le même titre existe déjà, le système af-
fiche un message d’erreur indiquant que le titre est déjà utilisé et
demande à l’administrateur de choisir un titre différent.
Post condition Les modifications apportées aux formations sont enregistrées et re-
Table 6.8 – Description textuelle du cas d’utilisation «Gérer les formations»
98
Annexe
Description textuelle du cas d’utilisation «Gérer les notifications» :
Cas d’utilisation Gérer les notifications

Scénario principal 1. L’administrateur clique sur l’icône de notification dans la
barre de navigation de l’application.
2. Le système affiche la liste des notifications disponibles pour
l’administrateur.
3. L’administrateur peut consulter le contenu d’une notifica-
tion en sélectionnant la notification dans la liste.
4. L’administrateur peut marquer une notification comme lue
après l’avoir consultée.
5. L’administrateur peut supprimer une notification en sélec-
tionnant la notification et en confirmant la suppression.
Scénario Alternatif Aucun scénario alternatif pour ce cas d’utilisation.
Post condition Les notifications lues sont marquées comme lues dans le sys-
tème et les notifications supprimées sont retirées de la liste
des notifications de l’administrateur.
Table 6.9 – Description textuelle du cas d’utilisation «Gérer les notifications»
99
Annexe
Description textuelle du cas d’utilisation «Gérer les discussions» :
Cas d’utilisa- Gérer les discussions

tion
Scénario prin- 1. L’administrateur accède à la liste des discussions dans l’application.
cipal 2. Le système affiche la liste des discussions existantes.
3. L’administrateur peut créer une nouvelle discussion en cliquant sur
le nom d’utilisateur après une recherche par nom.
4. Le système crée la nouvelle discussion et l’ajoute à la liste des
discussions.
5. L’administrateur peut consulter une discussion en sélectionnant la
discussion dans la liste.
6. Le système affiche les détails de la discussion, y compris les messages
échangés.
7. L’administrateur peut envoyer un message dans la discussion.
8. Le système enregistre le message dans la discussion.
9. L’administrateur peut supprimer un message de la discussion en
sélectionnant le message et en confirmant la suppression.
10. Le système supprime le message de la discussion.
11. L’administrateur peut supprimer une discussion en sélectionnant
la discussion et en confirmant la suppression.
12. Le système supprime la discussion de la liste des discussions.
Scénario Al- 3a. Si aucun résultat ne correspond à la recherche par nom d’utilisa-
ternatif teur, le système affiche un message indiquant qu’aucun utilisateur n’a
été trouvé.
Post condition Les modifications apportées aux discussions sont enregistrées et reflé-
tées dans la base de données du système.
Table 6.10 – Description textuelle du cas d’utilisation «Gérer les discussions»
100
Annexe
Diagramme de séquence « Modifier publication » La figure 6.14 ci-dessous montre

l’interaction entre l’administrateur et les différentes interfaces pour modifier une publication.
Figure 6.14 – Diagramme de séquence «Modifier publication»
101
Annexe
Diagramme de séquence « Supprimer publication » La figure 6.15 ci-dessous

montre l’interaction entre l’administrateur et les différentes interfaces pour supprimer une
publication.
Figure 6.15 – Diagramme de séquence «Supprimer publication»
102
Annexe
Chapitre 5
Diagramme de cas d’utilisation affiné :
Diagramme de cas d’utilisation affiné «Gérer les discussions» :
Figure 6.16 – Diagramme de cas d’utilisation affiné «Gérer les discussions»
Diagramme de cas d’utilisation affiné de «Gérer le profil» :
Figure 6.17 – Diagramme de cas d’utilisation affiné de «Gérer le profil»
103
Annexe
Diagramme de cas d’utilisation affiné «Consulter les formations» :
Figure 6.18 – Diagramme de cas d’utilisation affiné «Consulter les formations»
Diagramme de cas d’utilisation affiné «Gérer les notification» :
Figure 6.19 – Diagramme de cas d’utilisation affiné «Gérer les notification»
104
Annexe
Diagramme de cas d’utilisation affiné «Consulter les workshops» :
Figure 6.20 – Diagramme de cas d’utilisation affiné «Consulter les workshops»
Diagramme de cas d’utilisation affiné «S’authentifier» :
Figure 6.21 – Diagramme de cas d’utilisation affiné «S’authentifier»
105
Annexe
Description textuelle
Description textuelle du cas d’utilisation «S’authentifier» :
Cas d’utilisa- S’authentifier

tion
Acteurs Utilisateur
Pré condition L’utilisateur doit avoir un compte valide dans le système
Scénario prin- 1. L’utilisateur accède à la page de connexion de l’application.
cipal 2. Le système affiche le formulaire de connexion, demandant à l’utili-
sateur de saisir son email et son mot de passe.
3. L’utilisateur saisit son email et son mot de passe.
4. Le système vérifie les informations d’identification.
5. Si les informations sont valides, le système authentifie l’utilisateur
et lui accorde l’accès aux fonctionnalités réservées aux utilisateurs.
6. Le système affiche la page d’accueil de l’utilisateur.
7. Le cas d’utilisation se termine.
Scénario Al- 4a. Si les informations d’identification fournies par l’utilisateur sont
ternatif incorrectes, le système affiche un message d’erreur et l’utilisateur reste
sur la page de connexion. L’utilisateur peut réessayer de saisir ses
informations d’identification.
Post condition Utilisateur authentifié
106
Annexe
Description textuelle du cas d’utilisation «Gérer le profil» :
Cas d’utilisation Gérer le profil

Acteurs Utilisateur
Pré condition L’utilisateur doit être authentifié dans le système
Scénario principal 1. L’utilisateur accède à sa page de profil dans l’application.
2. Le système affiche les informations actuelles du profil de
l’utilisateur, telles que le nom, l’email, l’avatar, les liens (Gi-
thub, GitLab, LinkedIn), la description, le badge, le score et
les publications partagées.
3. L’utilisateur peut modifier son nom en saisissant un nou-
veau nom.
4. L’utilisateur peut modifier son email en saisissant une nou-
velle adresse email.
5. L’utilisateur peut modifier son mot de passe en saisissant
un nouveau mot de passe.
6. L’utilisateur peut modifier son avatar en sélectionnant une
nouvelle image parmi une liste prédéfinie d’avatars dispo-
nibles.
7. L’utilisateur peut ajouter des liens vers son profil Github,
GitLab ou LinkedIn en saisissant les URL correspondantes.
8. L’utilisateur peut ajouter une description à son profil en
saisissant du texte.
9. L’utilisateur peut consulter son badge et son score, qui sont
calculés en fonction de ses interactions dans l’application.
10. L’utilisateur peut consulter les publications qu’il a parta-
gées dans l’application.
11. L’utilisateur peut sauvegarder les modifications apportées
à son profil.
12. Le système enregistre les modifications du profil de l’uti-
lisateur dans la base de données.
107
Annexe
Scénario Alternatif 4a. Si l’adresse email est déjà utilisée par un autre compte, le
système affiche un message d’erreur indiquant que l’email est
déjà enregistré et demande à l’utilisateur de choisir une autre
adresse email.
Post condition Les modifications apportées aux profil sont enregistrées et re-
Table 6.12 – Description textuelle du cas d’utilisation «Gérer le profil»
Description textuelle du cas d’utilisation «Consulter les formations» :
Cas d’utilisation Consulter les formations

Acteurs Utilisateur
Scénario princi- 1. L’utilisateur accède à la page de challenges dans l’application.
pal 2. Le système affiche la liste des formations disponibles.
3. L’utilisateur peut parcourir les formations pour consulter les
détails de chaque formation, tels que le titre, la description, etc.
4. L’utilisateur peut participer à une formation.
5. Le système enregistre la participation de l’utilisateur.
6. L’utilisateur peut ajouter un feedback au formations.
7. Le système enregistre le feedback de l’utilisateur.
Scénario Alter- 4a. Si l’utilisateur a déjà participé au formation sélectionné, le sys-
natif tème affiche un message indiquant que l’utilisateur a déjà participé.
6a. Si l’utilisateur a déjà ajouté un feedback pour la formation sé-
lectionné, le système affiche un message indiquant que l’utilisateur
a déjà ajouté un feedback.
Post condition Le système enregistre la participation de l’utilisateur et son feed-
back pour la formation.
Table 6.13 – Description textuelle du cas d’utilisation «Consulter les formations»
108
Annexe
Description textuelle du cas d’utilisation «Gérer les discussions» :
Cas d’utilisation Gérer les discussions

Acteurs Utilisateur
Scénario princi- 1. L’utilisateur accède à la liste des discussions dans l’application.
pal 2. Le système affiche la liste des discussions existantes.
3. L’utilisateur peut créer une nouvelle discussion en cliquant sur
le nom d’utilisateur.
4. Le système crée la nouvelle discussion et l’ajoute à la liste des
discussions.
5. L’utilisateur peut consulter une discussion en sélectionnant la
discussion dans la liste.
6. Le système affiche les détails de la discussion, y compris les mes-
sages échangés.
7. L’utilisateur peut envoyer un message dans la discussion.
8. Le système enregistre le message dans la discussion.
9. L’utilisateur peut supprimer un message de la discussion en sé-
lectionnant le message et en confirmant la suppression.
10. Le système supprime le message de la discussion.
11. L’utilisateur peut supprimer une discussion en sélectionnant la
discussion et en confirmant la suppression.
12. Le système supprime la discussion de la liste des discussions.
Scénario Alter- Aucun scénario alternatif dans ce cas d’utilisation.

natif
Post condition Les modifications apportées aux discussions sont enregistrées et re-
Table 6.14 – Description textuelle du cas d’utilisation «Gérer les discussions»
109
Annexe
Description textuelle du cas d’utilisation «Consulter les workshops» :
Cas d’utilisation Consulter les workshops

Acteurs Utilisateur
Scénario princi- 1. L’utilisateur accède à la page de challenges dans l’application.
pal 2. Le système affiche la liste des workshops disponibles.
3. L’utilisateur peut parcourir les workshops pour consulter les dé-
tails de chaque workshop, tels que le titre, la description, etc.
4. L’utilisateur peut participer à un workshop.
5. Le système enregistre la participation de l’utilisateur.
6. L’utilisateur peut ajouter un feedback au workshop.
7. Le système enregistre le feedback de l’utilisateur.
Scénario Alter- 4a. Si l’utilisateur a déjà participé au workshop sélectionné, le sys-
natif tème affiche un message indiquant que l’utilisateur a déjà participé.
6a. Si l’utilisateur a déjà ajouté un feedback pour le workshop sé-
lectionné, le système affiche un message indiquant que l’utilisateur
a déjà ajouté un feedback.
Post condition Le système enregistre la participation de l’utilisateur et son feed-
back pour le workshop.
Table 6.15 – Description textuelle du cas d’utilisation «Consulter les workshops»
110

Pfe Med Yassine Hadda 2023

Transféré par

Droits d'auteur :

Formats disponibles

Pfe Med Yassine Hadda 2023

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

Pfe Med Yassine Hadda 2023

Transféré par

Droits d'auteur :

Formats disponibles

Dédicaces

1 Cadre général du projet 3

2 Spécification des besoins 13

2.3.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.6 Revue du sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Intégration d’un Système de Recommandation basé sur l’API OpenAI 73

6.5.3 Evaluation du modèle utilisé . . . . . . . . . . . . . . . . . . . . . . . 80

1.1 Logo de Diginov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Architecture physique de l’application web [1] . . . . . . . . . . . . . . . . . 22

3.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Diagramme de cas d’utilisation pour l’Administrateur . . . . . . . . . . . . . 44

5.1 Diagramme de cas d’utilisation «Utilisateur» . . . . . . . . . . . . . . . . . . 61

6.1 Diagramme de séquence "ajouter publication" avec OpenAI . . . . . . . . . 78

6.2 Fonction "generateChatgptResponse" . . . . . . . . . . . . . . . . . . . . . . 79

6.5 Diagramme de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

1.1 Tableau comparative des solutions existantes . . . . . . . . . . . . . . . . . . 8

2.1 Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Backlog du Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Backlog du Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1 Backlog du Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.1 Backlog du Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.4 Description textuelle du cas d’utilisation «S’authentifier» . . . . . . . . . . . 94

6.11 Description textuelle du cas d’utilisation «S’authentifier» . . . . . . . . . . . 106

SEO Search Engine Optimization

DevOps Development (Dev) and Operations (Ops)

UML Unified Modeling Language

CPU Central Processing Unit

RAM Random Access Memory

SSD Solid-State Drive

HDD Hard Disk Drive

API Application Programming Interface

JSON JavaScript Object Notation

HTTP HyperText Transfer Protocol

HTTP HyperText Transfer Protocol

CRUD Create Read Update Delete

JWT JSON Web TokenDelete

DevTeam Development Team

REST Representational State Transfer

QCM Questionnaire à Choix Multiples

GPT Generative Pre-trained Transformer

TPM Transactions Per Minute

RPM Requests Per Minute

1.1 Présentation de l’organisme d’accueil

DIGINOV est une société de développement et de conseil informatique, fondée en 2016,

Figure 1.1 – Logo de Diginov

1.1.2 Expertises de l’entreprise

1.2 Contexte du projet

1.3 Présentation du projet

1.3.2 Étude de l’existant

déjà utilisées pour partager et enrichir les connaissances techniques.

1.3.3 Critique de l’existant

1.3.3.1 Microsoft Teams

1.3.3.3 Solution proposée

DIGINOV s’efforce toujours de moderniser la réalisation de ses projets tout en adoptant

connaissances, de participer à des challenges, des formations et des workshops, et de gagner

1.3.3.4 Etude comparative entre les solutions

Flexibilité Convivialité Fonctionnalités Sécurité Contrôle de

Table 1.1 – Tableau comparative des solutions existantes

1.4 Méthodologie de travail