Réf : AU : 2022-2023

Université de Sousse

Ecole Nationale d’Ingénieurs de Sousse

Mémoire de Projet de Fin d'Études

Présenté en vue de l’obtention du diplôme d’

Ingénieur en Génie Informatique Appliquée

Option : Ingénierie des systèmes intelligents

Étude, conception et réalisation de l’intégration d’un

CMS de type “headless” au sein d’une solution de
commerce électronique adressant plusieurs pays en
Europe

Réalisé par :

Siwar SOUIBGUI

Soutenu le 22/06/2023 devant le jury

Président : Mme Manel ABDELHEDI, ENISO

Rapporteur : Mme Saoussen BEN JABRA, ENISO
Encadrant académique : Mme Takoua ABDELLATIF, ENISO
Encadrant professionnel : Mme Farah NASRI, DECADE
Dédicace

“ Je dédie ce travail :

À ma chère mère Mouna et à mon cher père Karem qui

n’ont jamais cessé de me supporter, me soutenir et
m’encourager durant mes années d’études.

Qu’ils trouvent ici le témoignage de ma profonde gratitude et

reconnaissance.

À mes frères Mohamed & Zied et mes soeurs Nour & Eya
qui me donnent de l’amour et de la vivacité.

À mes merveilleuses grand-méres Aicha & Jamila, bien

qu’elles ne soient plus parmi nous, je suis certaine qu’elles
veillent sur moi avec fierté et me soutiennent de tout leur
amour depuis l’au-delà. Que leur âme repose en paix.

À toutes mes amis Samar, Malek, Chaima, Waad, Beki,

Kawther, Refka & Nour qui m’ont soutenue et étaient
présents pour moi. Merci infiniment d’être là à côté de moi.

Merci !

”
- Siwar

2
Remerciements

Après avoir achevé ce travail, je me sens redevables aux personnes qui m’ont aidé à
élaborer le présent rapport. Je tiens à exprimer ma profonde gratitude, mes vifs remercie-
ments et ma sincère reconnaissance à mes encadrants :

Mme. ABDELLATIF Takoua mon encadrante académique pour m‘avoir soutenu

tout au long de stage et pour ses précieuses directives qu’elle m’a prodiguées tout au long
de la rédaction de ce rapport. Je tiens à lui exprimer toute mon admiration et ma recon-
naissance.

Mon superviseur professionnel Mme. NASRI Farah ainsi que mon tuteur Mme. IBEN
AMOR Amal, qui malgré leurs responsabilités et leurs occupations, ont toujours eu le
temps pour m’écouter, conseiller et n’ont jamais renoncé à m’orienter vers les bonnes so-
lutions avec un degré de patience et de professionnalisme sans égal. Pour leur présence et
leur expertise qui m’ont permis d’approfondir mes connaissances et d’accomplir ce travail
avec confiance.

Je tiens aussi à adresser mes plus sincères remerciements à l’ensemble du corps admi-
nistratif et enseignant de l’École Nationale d’Ingénieurs de Sousse , pour avoir porté un vif
intérêt à notre formation, et pour avoir accordé de l’attention et de l’énergie, et ce, dans
un cadre agréable de respect.

Finalement, Je profite de cette occasion pour remercier les membres du jury pour
l’honneur qu’ils me font de bien vouloir juger ce travail. Veuillez trouver dans ce rapport
les qualités de clarté et de motivation qu’ils attendent.

3
Résumé

Aujourd’hui l’e-commerce connaît une croissance exponentielle, offrant aux entreprises

la possibilité d’atteindre un public mondial. Cependant, la gestion du contenu au sein de ces
plateformes, avec un CMS d’architecture traditionnelle peut être complexe et nécessite une
personnalisation avancée. Le présent rapport est le fruit d’un travail réalisé pendant quatre
mois de stage au sein de l’entreprise DECADE dont le but est d’assurer une meilleure
gestion de contenu en faisant l’étude, la conception et la réalisation de l’intégration un
CMS (Content Management System) de type headless au sein d’une solution commerce en
ligne adressant plusieurs pays en Europe dans le cadre de réarchitecture d’une plateforme
commerce B2B (basée sur SAP commerce) RUBIX.

Mots clés : E-commerce, Systéme de gestion de contenu, CMS Headless, Java EE,
Spring MVC, API, SAP commerce, Hybris, SCRUM, Multilingue, Restriction.

4
Abstract

Today e-commerce is growing exponentially, offering businesses the opportunity to reach

a global audience. However, managing content within these platforms with a traditional
architecture CMS can be complex and requires advanced customization. This report is the
result of work carried out during a four-month internship within the company DECADE,
the aim of which is to ensure better content management by studying, designing and
carrying out the integration a headless CMS (Content Management System) within an
e-commerce solution addressing several countries in Europe as part of the re-architecture
of a B2B commerce platform (based on SAP commerce) RUBIX.

Keywords : E-commerce, Content management system, Headless CMS, Java EE,

Spring MVC, API, SAP commerce, Hybris, SCRUM, Multilingual, Restriction.

5
Table des matières

Introduction 13

1 Présentation générale 15
1.1 Contexte de projet de fin d’étude . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . 15
1.2.1 Présentation de la société DECADE . . . . . . . . . . . . . . . . . 16
1.2.2 Organigramme de l’entreprise . . . . . . . . . . . . . . . . . . . . . 16
1.2.3 Services et Missions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.4 Partenaires de DECADE . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Présentation du client Rubix . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.2 Approches du travail . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.3 Méthodologie de gestion de projet . . . . . . . . . . . . . . . . . . . 20
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2 Étude préalable 23
2.1 E-Commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1 Présentation de l’e-commerce : . . . . . . . . . . . . . . . . . . . . . 23
2.1.2 Les typologies de l’e-commerce . . . . . . . . . . . . . . . . . . . . . 24
2.2 La plateforme e-commerce SAP-Hybris . . . . . . . . . . . . . . . . . . . . 24
2.2.1 Présentation d’Hybris : . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.2 Les outils d’administration de la plateforme Hybris . . . . . . . . . 25
2.3 Système de gestion de contenu CMS . . . . . . . . . . . . . . . . . . . . . . 25

6
Table des matières 7

2.3.1 Qu’est ce qu’un CMS ? . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.2 Les types d’architecture des CMS . . . . . . . . . . . . . . . . . . . 26
2.4 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.1 CMS Cockpit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6 Objectifs de la solution envisagée . . . . . . . . . . . . . . . . . . . . . . . 29
2.7 Choix de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8 Étude comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8.1 Présentation des CMS . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8.3 Gestion de la Restriction . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8.4 Gestion de contenu multilingue . . . . . . . . . . . . . . . . . . . . 35
2.8.5 Export/Import des données . . . . . . . . . . . . . . . . . . . . . . 35
2.8.6 Choix de l’outil CMS . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3 Analyse & spécification des besoins 38

3.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Diagrammes des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1 Diagramme de cas d’utilisation général : . . . . . . . . . . . . . . . 40
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 Étude Conceptuelle 45
4.1 Conception globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.1 Architecture Physique . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.1.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.1.3 Architecture Logique : Côté client . . . . . . . . . . . . . . . . . . . 49
4.1.4 Structure : Côté Client . . . . . . . . . . . . . . . . . . . . . . . . . 50
Table des matières 8

4.2 Conception Statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.1 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.2 Documentation de l’API : GetUser . . . . . . . . . . . . . . . . . . 53
4.3 Conception dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 Mise en oeuvre de la solution 57

5.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.2 Environnement Web . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.1.3 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2.1 Configuration du contenu sur le CMS . . . . . . . . . . . . . . . . . 60
5.2.2 Exposition du contenu configuré sur le Webshop . . . . . . . . . . . 65
5.3 Évaluation des performances . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3.1 Lighthouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3.2 Mesure des performances . . . . . . . . . . . . . . . . . . . . . . . . 74
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Conclusion générale 76

Annexes 77

Webographie 80
Table des figures

1.1 Organigramme de DECADE . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2 Les clients B2B et B2C de DECADE . . . . . . . . . . . . . . . . . . . . . 17
1.3 Les partenaires de DECADE . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Transformation architecturale de la plateforme Rubix . . . . . . . . . . . . 19
1.5 Exemple de cycle de développement Agile . . . . . . . . . . . . . . . . . . 21
1.6 Cycle de vie de la méthodologie scrum. . . . . . . . . . . . . . . . . . . . . 21

2.1 Architecture d’un CMS couplé . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2 Architecture d’un CMS Headless . . . . . . . . . . . . . . . . . . . . . . . 27
2.3 Éditer un contenu dans le CMSCockpit . . . . . . . . . . . . . . . . . . . . 28
2.4 Comparaison des performances . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5 Gestion de Restriction par groupe d’utilisateurs pour les deux CMS . . . . 34
2.6 Gestion de la restriction temporelle pour les deux CMS . . . . . . . . . . . 35
2.7 Export/Import en Directus . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.8 Export/Import en Strapi . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . 41

3.2 Diagramme de cas d’utilisation de configurer le Contenu . . . . . . . . . . 42
3.3 Diagramme de deux cas d’utilisation "Gérer les utilisateurs et les groupes
d’utilisateurs" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4 Diagramme de cas d’utilisation "Visualiser le contenu" de client . . . . . . 43

4.1 Architecture physique de la solution . . . . . . . . . . . . . . . . . . . . . . 46

4.2 Architecture logique de la solution . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Architecture logique : Architecture Redux . . . . . . . . . . . . . . . . . . 49

9
Table des figures 10

4.4 Diagramme de package : Côté client . . . . . . . . . . . . . . . . . . . . . . 51

4.5 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6 API GetUser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.7 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1 Interface de la connexion sur le CMS . . . . . . . . . . . . . . . . . . . . . 60

5.2 Interface de création d’une nouvelle page . . . . . . . . . . . . . . . . . . . 61
5.3 Les champs configurées pour une page . . . . . . . . . . . . . . . . . . . . 61
5.4 Ajout des carrousels des images sur la page . . . . . . . . . . . . . . . . . . 62
5.5 La liste des IDs des groupes des utilisateurs . . . . . . . . . . . . . . . . . 63
5.6 L’ajout du champ restriction dans une page . . . . . . . . . . . . . . . . . 63
5.7 La récupération de la liste des IDs . . . . . . . . . . . . . . . . . . . . . . . 64
5.8 Liste des produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.9 Composant Carrousel des produits . . . . . . . . . . . . . . . . . . . . . . 65
5.10 Ajouter un nouveau groupe d’utilisateur . . . . . . . . . . . . . . . . . . . 66
5.11 Attacher ce groupe à un client . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.12 Définir la restriction sur la page . . . . . . . . . . . . . . . . . . . . . . . . 67
5.13 Page introuvable, dans le cas le client est [Link] . . . . . . . . . . 67
5.14 Connexion échoué . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.15 Affichage de la page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.16 Carrousel des images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.17 la page Selection des Avantages Gigaphones sur CMS . . . . . . . . . . . . 69
5.18 Composant visible pour tous le monde . . . . . . . . . . . . . . . . . . . . 70
5.19 Connexion de l’utilisateur [Link] . . . . . . . . . . . . . . . 70
5.20 Pour l’utilisateur [Link] . . . . . . . . . . . . . . . . . . . . 71
5.21 Pour l’utilisateur [Link] . . . . . . . . . . . . . . . . . . . . . . . . 71
5.22 Relation OneToMany entre une page et les langues . . . . . . . . . . . . . 72
5.23 Un contenu multilingue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.24 Une page en anglais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.25 Une page en italien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.26 Un carrousel des produits . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Table des figures 11

5.27 Comparaison de résultat du test des performances . . . . . . . . . . . . . . 74

5.28 Mesure de la valeur FCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.29 La réponse de l’API Media . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.30 Retour de l’API Products . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.31 Retour de l’API SkuDetails . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Liste des acronymes

API Application Programming Interface

CMS Content Management System

HMC Hybris Management Console

HAC Hybris Administration Console

SAP Systems Applications Products in Data Processing

SEO Search Engine Optimization

UML Digital Unified Modeling Language

WCMS Web Content Management System

12
Introduction

Le commerce électronique est devenu un secteur indispensable de l’économie mondiale,

offrant aux entreprises la possibilité d’atteindre un public mondial et de maximiser leurs
ventes. Grâce à l’avènement des technologies web, les plateformes de commerce électronique
sont devenues des outils essentiels pour les entreprises qui souhaitent établir leur présence
en ligne, pénétrer de nouveaux marchés et offrir aux consommateurs une expérience d’achat
fluide et pratique. Pour atteindre ces objectifs, les entreprises font appel aux systèmes de
gestion de contenu, qui jouent un rôle essentiel dans les solutions e-commerce en permettant
une meilleure gestion du contenu.

Toutefois, la gestion du contenu sur les plateformes de commerce électronique, avec

les CMS d’architecture traditionnel peut se révéler complexe, surtout lorsque les besoins
d’une entreprise évoluent rapidement et exigent une personnalisation avancée. C’est là
que l’intégration d’un système de gestion de contenu headless (CMS headless) entre en
jeu, offrant une approche novatrice qui permet une plus grande flexibilité et une meilleure
séparation entre la gestion du contenu et sa présentation.

C’est dans cette optique que notre projet de fin d’études s’inscrit dont l’objectif est de
faire l’étude, la conception et la réalisation de l’intégration d ’un CMS de type headless
dans le cadre de réarchitecture d’une plateforme commerce B2B basée sur SAP Commerce
(anciennement SAP Hybris progiciel, leader mondial de solutions de commerce omnicanal).

Ce rapport de projet de fin d’étude se concentre sur l’étude et l’intégration d’un CMS
headless au sein d’une plateforme e-commerce de distribution des produits et services de
maintenance industrielle. L’objectif principal est de sélectionner le CMS approprié qui peut
répondre aux besoins de la solution ainsi d’explorer les avantages liés à cette intégration,
en mettant l’accent sur la recherche et l’analyse comparative des CMS headless disponibles
sur le marché.

Pour retracer l’acheminement chronologique de notre travail, ce rapport a été subdivisé

en cinque chapitres. Le premier chapitre "Présentation générale" s’intéresse à faire une
présentation de l’organisme d’accueil ainsi que le cadre général du projet. Par la suite on
entame le second chapitre "Étude préalable" qui présente une introduction générale sur

13
Introduction 14

l’e-commerce. Ensuite, nous nous pencherons sur la définition et les principes fondamen-
taux d’un CMS, et nous passerons en revue les différents CMS headless disponibles sur
le marché, en analysant leurs fonctionnalités clés, leurs avantages et leurs inconvénients.
Nous mettrons l’accent sur l’étude comparative de ces CMS, en mettant en évidence leurs
capacités à répondre aux besoins spécifiques d’une plateforme e-commerce. Le troisième
chapitre "Analyse des besoins" décrit la phase de l’analyse et la spécification des be-
soins. Où nous allons tout d’abord énumérer les acteurs, les besoins fonctionnels et non
fonctionnels de l’application, puis clarifier ses fonctionnalités à travers les différents dia-
grammes de cas d’utilisation. En outre le quatrième chapitre "Étude conceptuelle" est
consacré à l’étude conceptuelle du projet. Cette dernière mettra l’accent sur les principaux
diagrammes décrivant les différents scénarios de l’application. Enfin Le cinquième chapitre
"Mise en oeuvre" et le dernier sera dédié aux aspects relatifs à la réalisation de notre
projet. En fin nous clôturons le rapport par "une conclusion générale" qui présente une
analyse du travail réalisé au sein de DECADE. Cette partie met en évidence non seulement
un résumé du travail effectué, mais aussi des propositions et des diverses perspectives.
Chapitre 1

Présentation générale

Ce premier chapitre est dédié d’abord pour la présentation de l’entreprise d’accueil,

DECADE, incluant une description de ses services, activités et partenaires. Nous procédons
ensuite à l’identification du projet RUBIX, au sein duquel notre solution sera intégrée. Nous
continuons en présentant le cadre général du projet, ainsi que ses objectifs.

1.1 Contexte de projet de fin d’étude

Dans le cadre de l’obtention de diplôme national d’ingénieur en génie informatique
appliquée option Ingénierie des systèmes intelligents, nous sommes ramenés à effectuer un
projet de fin d’études au sein de la société DECADE.

Ce projet touche à soumettre nos études universitaires et notre formation à l’École

Nationale d’Ingénieurs de Sousse, nous introduire à la vie professionnelle grâce à une mise
en pratique des nos connaissances acquises durant les trois ans d’études vécu au sein de
cet établissement.

Notre projet s’inscrit dans le cadre d’un projet de réarchitecture d’une plateforme com-
merce B2B basée sur SAP commerce. L’objectif est d’étudier, concevoir et réaliser l’inté-
gration d’un CMS headless au sein d’une solution commerce en ligne destinée à plusieurs
pays en Europe.

1.2 Présentation de l’organisme d’accueil

Notre stage a été réalisé au sein de la société DECADE Sousse que nous la présenterons
dans ce quit suit :

15
1.2. Présentation de l’organisme d’accueil 16

1.2.1 Présentation de la société DECADE

Créée par [Link] JERUSALMI à Paris en juin 1988, DECADE est une entreprise
française qui s’est implantée en Tunisie en 1998. Depuis ce jour elle a accompagné les
petites et grandes entreprises dans leur développement des solutions e-commerce.
Avec l’avènement du web, il y a 16 ans que DECADE s’est spécialisée dans l’e-commerce
et a commencé à accumuler des expériences et des réussites en réalisant des projets de com-
merce électronique à grande échelle, tant pour les entreprises B2C que pour les entreprises
B2B.
DECADE compte actuellement 210 collaborateurs travaillant depuis différents endroits,
notamment la France et la Tunisie. Le siège de l’entreprise se trouve à Paris, avec une autre
implantation à Lyon, tandis que le pôle technique est situé dans quatre sites en Tunisie, à
savoir Monastir, Tunis, Sfax et Sousse.
En 2022, DECADE a enregistré un chiffre d’affaires de 15.3 millions d’euros, soit une
croissance de 10%. L’entreprise est détenue à 100% par ses dirigeants, managers et salariés,
ce qui témoigne d’un engagement fort de tous les membres de l’équipe [1].

1.2.2 Organigramme de l’entreprise

Pour garantir sa réussite, et pour atteindre efficacement ses objectifs, DECADE a bien
conçu son organisation qui est composée de six directions principales. Chacune de ces di-
rections a des responsabilités spécifiques pour assurer le bon fonctionnement de l’entreprise
dans son ensemble.
La figure 1.1 expose les six différentes directions ainsi que les responsabilités de chacune :
1.2. Présentation de l’organisme d’accueil 17

Figure 1.1 – Organigramme de DECADE

1.2.3 Services et Missions

DECADE est une entreprise qui se spécialise dans la gestion de projets liés au dévelop-
pement et à l’intégration de solutions de commerce électronique. Leur offre met l’accent
sur la fiabilité de ses projets tout au long de leur cycle de vie, couvrant des étapes telles
que la préparation, le lancement, le développement, la maintenance, le renouvellement, la
refonte et la réflexion stratégique.

La figure 1.2 présente les différents clients que DECADE a accompagné et jusqu’à
aujourd’hui DECADE fait preuve de sa réussite en garantissant à ces clients des solutions
fiables.

Figure 1.2 – Les clients B2B et B2C de DECADE

1.3. Présentation du client Rubix 18

1.2.4 Partenaires de DECADE

DECADE collabore avec un réseau de partenaires de premier plan dans le domaine des
technologies de l’information pour offrir des solutions e-commerces innovantes et adaptées
aux besoins de ses clients. L’entreprise travaille en étroite collaboration avec des fournis-
seurs de logiciels de premier ordre qui sont présentés dans la figure 1.3 :

Figure 1.3 – Les partenaires de DECADE

Ces partenariats permettent à DECADE de rester à la pointe de la technologie et d’offrir

des solutions à la pointe de l’innovation à ses clients. En travaillant avec ces partenaires
stratégiques, DECADE peut proposer à ses clients des solutions informatiques sur mesure
et hautement performantes, tout en garantissant la qualité et la fiabilité de ses prestations.

1.3 Présentation du client Rubix

Rubix est une entreprise européenne spécialisé dans la distribution business to business
(B2B) de composants et de services industriels, avec une présence de 650 agences com-
merciales dans 23 pays et un chiffre d’affaires de 2,2 milliards d’euros. Rubix fournit une
large gamme de produits et de services, allant de la maintenance et la réparation d’équi-
pements industriels à la fourniture de produits de transmission de puissance, de produits
hydrauliques et pneumatiques, de produits de protection et de sécurité, et bien plus encore
[2].

1.4 Présentation du projet

Cette section vise à fournir un aperçu global du projet en expliquant la raison pour
laquelle il a été initié, les tâches requises pour sa réalisation et la méthodologie utilisée tout
au long de son exécution.
1.4. Présentation du projet 19

1.4.1 Motivation

Comme toute entreprise de commerce électronique, Rubix accorde une importance à

l’amélioration des performances de son site web ,consciente que tout retard de réponse
peut entraîner d’importantes pertes financières. Également, le référencement joue un rôle
crucial dans le succès de son projet. Parallèlement notre client cherche toujours à assurer
une meilleure expérience client et bien évidemment donc une meilleure gestion de contenu
pour ses développeurs.
Pour accomplir ce défis, l’équipe RUBIX à décider de migrer d’une architecture mono-
lithique avec des composants fortement liés à l’outil SAP Hybris, vers une architecture
découplé. Ces quatres blocs sont séparés et communiquent entre eux à travers des APIs.
La figure 1.4 éclaircie la transformation architecturale de la plateforme :

Figure 1.4 – Transformation architecturale de la plateforme Rubix

La plateforme va être découplé en quatres services : front, cms et search, qui seront
changé en utilisant des technologies et des pratiques adaptées et à jour. Le moteur de
règles métier (Legacy business rule engine) va être mis à jour vers la dernière version
d’hybris.
C’est dans cette optique que notre projet de fin d’études s’inscrit. Nous allons faire l’étude,
la conception et la réalisation de l’intégration d’un nouveau CMS de type headless au sein
d’une solution commerce en ligne adressant plusieurs pays en europe. Cette solution va
permettra une gestion plus souple et efficace du contenu de la plateforme.

1.4.2 Approches du travail

La réussite de la mise en oeuvre de cette solution est tributaire d’une planification

minutieuse et rigoureuse, ainsi que d’un déroulement méthodique des différentes étapes
du projet. Il est crucial de respecter chaque étape du processus afin de garantir le bon
déroulement de la réalisation du projet et l’obtention des résultats escomptés :
1.4. Présentation du projet 20

— Étude préalable : Lors de cette phase, l’accent est mis sur l’étude approfondie du
domaine et du contexte global du projet, ainsi que sur l’identification et l’évaluation
des outils existants et nécessaires pour la réalisation de la solution.

— Analyse et Spécification des besoins : Il s’agit d’identifier avec précision les

différentes fonctionnalités et les exigences spécifiques que la solution devra remplir
pour répondre aux attentes des parties prenantes. Cette partie est cruciale qui ser-
vira de guide tout au long de la réalisation du projet.

— Conception : Cette partie sera consacrée pour exposer les différents diagrammes
UML qui vont clarifier la façon avec laquelle notre solution doit être mise en place
ainsi que les architectures physique et logicielle.

— Réalisation : Au cours de cette phase, le développement de la solution est réalisé,

ainsi que les différentes étapes de tests et de validations. Cette étape consiste à
mettre en œuvre la solution conformément aux besoins et aux spécifications définis
précédemment, en utilisant les technologies et les outils appropriés.

1.4.3 Méthodologie de gestion de projet

Une bonne gestion de projet et une conduite efficace, impliquant la mise en évidence
d’une méthodologie de gestion de projet assurant le bon déroulement du travail jusqu’à
aboutir à sa réalisation et sa mise en place conformément aux critères désirés.

En effet le projet en question est fortement influencé par les acteurs de son domaine.
Pour cette raison, l’équipe de projet se doit d’être constamment à l’écoute des besoins
de son client et prête à s’adapter à de nouveaux changements. Afin de répondre à ces exi-
gences, l’équipe a choisi d’utiliser un processus de développement agile, plus spécifiquement
SCRUM.

Méthode Agile

Pour répondre aux exigences de notre projet, nous avons opté pour un processus de dé-
veloppement agile, figure 1.5 ,plus efficaces et moins rigides que les méthodes [Link]
méthodes agiles offrent une plus grande flexibilité et une meilleure visibilité dans la gestion
du projet, ce qui permet de générer un produit de haute qualité. De plus, elles permettent
à l’équipe de parcourir les risques beaucoup plus rapidement qu’avec les outils de gestion
de projet traditionnels [3].
1.4. Présentation du projet 21

Figure 1.5 – Exemple de cycle de développement Agile

Méthode Scrum

SCRUM, figure 1.6, est par essence une évolution de la méthodologie agile. Elle est défi-
nie par un ensemble de pratiques qui doivent être inclues dans la phase de développement.
SCRUM est subdivisée en des blocs temporaires appelés Sprint, qui durent généralement de
deux à quatre semaines. Chaque Sprint est une entité à part et est planifié collectivement
par tous les membres de l’équipe. Durant les Sprints, une réunion quotidienne se déroule
pendant quinze minutes où chaque membre discute les tâches qu’il a réalisé, les différents
obstacles qu’il a rencontré et son futur plan pour les vingt-quatre heures à venir.

Figure 1.6 – Cycle de vie de la méthodologie scrum.

Les rôles des intervenants sont les suivants :

— Product Owner : Dans la majorité des projets, le responsable produit (product

1.5. Conclusion 22

owner) est le responsable de l’équipe projet client. C’est lui qui va définir et priori-
ser la liste des fonctionnalités du produit et choisir la date et le contenu de chaque
sprint sur la base des valeurs (charges) qui lui sont communiquées par l’équipe.

— Scrum Master : Véritable facilitateur sur le projet, il veille à ce que chacun puisse
travailler au maximum de ses capacités en éliminant les obstacles et en protégeant
l’équipe des perturbations extérieures.

— Équipe de développement : elle regroupe l’ensemble des rôles habituellement né-

cessaires à un projet, à savoir le concepteur, le développeur, le testeur, etc. L’équipe
s’organise elle-même et elle reste inchangée pendant toute la durée d’un sprint.

1.5 Conclusion
Dans ce premier chapitre, nous avons commencé par présenter l’organisme qui nous
a accueilli pour notre projet de fin d’études, ainsi que le client pour lequel nous avons
travaillé, RUBIX. Ensuite, nous avons décrit le contexte général de notre projet ainsi que
les étapes qui ont menées à la réalisation de la solution. Nous avons conclu ce chapitre
en exposant la méthodologie que nous avons utilisée durant notre stage. Dans le prochain
chapitre, nous allons fournir des explications plus détaillées sur notre solution proposée, en
introduisant quelques notions de base importantes.
Chapitre 2

Étude préalable

Ce chapitre a pour but d’approfondir l’étude préalable de notre projet, qui se révèle in-
dispensable et cruciale pour mener à bien les prochaines étapes de sa réalisation. En premier
lieu nous présenterons les concepts fondamentaux en relation avec notre projet notamment
le domaine de l’e-commerce ainsi que la plateforme SAP Hybris. En deuxième lieu, nous
procéderons à une analyse critique des différents types de CMS existants afin d’exposer
les problématiques qui va nous permettre de mieux cerner les enjeux et de proposer une
solution pertinente pour répondre à l’exigence de notre projet.

2.1 E-Commerce
Cette partie du rapport, met l’accent sur la définition du commerce électronique, un
domaine central de notre projet. Cette section jettera les bases nécessaires pour explorer
les typologies spécifiques du commerce électronique, qui seront abordées par la suite.

2.1.1 Présentation de l’e-commerce :

Dans l’absolu, le commerce électronique, l’e-commerce ou éventuellement le commerce
en ligne un secteur en pleine expansion, désigne simplement l’action d’acheter ou de vendre
de produits et services par l’intermédiaire des réseaux informatiques.

Historique :

L’e-commerce a connu une évolution remarquable depuis ses débuts dans les années
1990. Avec l’introduction du World Wide Web et l’émergence d’entreprises emblématiques
telles qu’Amazon, eBay et Alibaba, l’e-commerce s’est rapidement répandu, permettant

23
2.2. La plateforme e-commerce SAP-Hybris 24

aux consommateurs d’acheter une large gamme de produits et de services en ligne.

Depuis les années 2010, et avec l’explosion des appareils mobiles, tels que les smartphones
et les tablettes, qui ont permis aux consommateurs d’accéder facilement à l’e-commerce où
qu’ils se trouvent. Ce domaine continue de se développer rapidement, avec une expansion
mondiale et une diversification constante des produits et des services proposés en ligne. [4]

2.1.2 Les typologies de l’e-commerce

Il existe bien sûr tout un éventail de modèles économiques entre le vendeur et l’ache-
teur. Les modèles d’e-commerce varient énormément et comprennent de nombreux types
d’affaires. Voici une liste des différents types d’échanges d’e-commerce :
— B2B (Business-to-Business) : C’est une forme du commerce en ligne dont les
acteurs sont des entreprises ou des organisations.(les clients finaux sont aussi des
professionnels)
— B2C (Business-to-Consumer) : C’est l’E-commerce le plus visible sur Internet
et qui est à destination des particuliers ou les clients finaux achètent directement
des biens ou des services depuis les sites web des entreprises.
— C2B (Consumer-to-Business) : C’est l’échange électronique dans lequel les
produits ou les services sont proposés aux entreprises par les consommateurs.
— C2C (Consumer-to-Consumer) : Il s’agit d’une typologie du commerce électro-
nique ou l’échange des produit se fait entre les particuliers qui peuvent eux-mêmes
utiliser des sites dédiés.

2.2 La plateforme e-commerce SAP-Hybris

Pour la mise en oeuvre de notre projet, nous avons choisie la plateforme SAP Hybris,
une solution de commerce électronique que nous la présenterons dans ce qui suit.

2.2.1 Présentation d’Hybris :

Fondée en 1997, Hybris est une plateforme de commerce électronique et de gestion de
l’expérience client développée par SAP, une entreprise spécialisée dans le domaine des so-
lutions logicielles d’entreprise. Hypris offre une suite complète d’outils et de fonctionnalités
pour permettre aux entreprises de créer, de gérer et de développer leurs activités de com-
merce en ligne de manière puissante.
Reconnue comme leader mondiale grâce aux capacités de commerce électronique omnica-
nales qu’elle propose, ce qui signifie qu’elle permet aux entreprises de fournir une expérience
cohérente et fluide à leurs clients sur différents canaux, tels que les sites web, les applications
2.3. Système de gestion de contenu CMS 25

mobiles, les réseaux sociaux. De plus elle inclut également des fonctionnalités développées
de gestion des produits, des catalogues, des commandes, des paiements, de la logistique et
de la personnalisation [5].

2.2.2 Les outils d’administration de la plateforme Hybris

Pour permettre à ces utilisateurs de gérer efficacement leur site e-commerce, la plate-
forme Hybris propose plusieurs outils d’administration. Voici quelques-uns des principaux
outils d’administration disponibles :

— Hybris Management Console (HMC) : Cet outil permet de gérer la configura-

tion du site et de ses composants. Il permet de gérer les propriétés du système, les
paramètres de sécurité, la gestion des utilisateurs et des rôles, ainsi que la mise à
jour et la gestion du système de gestion de contenu (WCMS).
— Hybris Adminstration Console (HAC) : C’est l’application web par défaut
d’administration d’Hybris. Elle offre des fonctionnalités pour l’administration, la
surveillance et la configuration du commerce suite. Cet outil est destiné aux déve-
loppeurs pour mettre à jour le système hybris à chaque modification de structure
du système hybris. Il permet aussi d’exporter, d’importer manuellement des fichiers
ImpEx et d’exécuter des requêtes sur la base de données via le moteur de recherche
flexible search.
— Hybris WCMS Cockpit (Web Content Management System) : C’est un sys-
tème de gestion de contenu intégré à la plateforme. Il permet de gérer les pages web,
les bannières, les promotions, les contenus statiques, etc. Les utilisateurs peuvent
facilement créer, modifier et publier du contenu sur le site.

2.3 Système de gestion de contenu CMS

Le besoin principale de notre projet consiste à intégrer un CMS de type headless au
sein de la plateforme Rubix. Cette partie donc vise à définir le concept de CMS et présenter
ses différents types.

2.3.1 Qu’est ce qu’un CMS ?

Un système de gestion de contenu (CMS) est une plateforme qui simplifie la
création, la modification et la publication de contenu sur un site web. Il englobe différents
types de contenu tels que du texte, des images, des vidéos, des fichiers audio, etc. En plus
de cela, un CMS propose des fonctionnalités de gestion des utilisateurs, de gestion des
2.3. Système de gestion de contenu CMS 26

médias, de gestion des commentaires et de personnalisation du site web.[6] Parmi les CMS
les plus connus , on cite WordPress, Drupal, Joomla, Typo3, etc.

Pourquoi un CMS ? Avoir une vitrine électronique conviviale et robuste, nécessite

une gestion efficace et pertinente de son contenu, c’est pour cela la plupart des entreprises
tournent vers le CMS qui s’avère un outil idéal de gestion de contenu en offrant une mul-
tiplicité des fonctionnalités telles que :

— Une interface conviviale : permet aux utilisateurs, même sans connaissances

techniques d’organiser facilement le contenu.
— Collaboration efficace : offre des fonctionnalités de gestion des utilisateurs, per-
mettant d’attribuer des rôles et des autorisations spécifiques à chaque utilisateur.
Cela facilite la collaboration entre les rédacteurs, les éditeurs, et les administrateurs
du site.
— Personnalisation et flexibilité : permet aux utilisateurs de modifier facilement
l’apparence et la mise en page du site web en utilisant des thèmes et des modèles
prédéfinis.
— Optimisation pour les moteurs de recherche : intégre des fonctionnalités d’op-
timisation pour les moteurs de recherche (SEO), telles que la gestion des balises
méta, les URL conviviales, la génération automatique de sitemaps, etc. Cela facilite
le référencement du site web et améliore sa visibilité dans les résultats des moteurs
de recherche.

2.3.2 Les types d’architecture des CMS

Les CMS sont toujours en évolution pour s’adapter aux nouvelles tendances technolo-
giques, c’est pour ça il existe deux types des CMS [7] :

CMS Traditionnel

Dans un CMS traditionnel, ou CMS couplé est un système qui fournit à la fois le
back-end et le front-end d’un site web ou d’une application. Dans un CMS traditionnel,
le back-end contient toutes les fonctionnalités du système, y compris la gestion des uti-
lisateurs, l’administration du contenu, la personnalisation du site, les fonctionnalités de
commerce électronique, etc. Le front-end utilise ces fonctionnalités pour afficher le contenu
et les fonctionnalités aux visiteurs du site. La figure ci-dessous présente l’architecture tra-
ditionnelle du CMS.
2.4. Étude de l’existant 27

Figure 2.1 – Architecture d’un CMS couplé

CMS Headless

Un CMS de type headless est une architecture ou la partie front-end est totalement
séparée de la partie back-end comme illustré dans la figure 2.2. Dans cette architecture
le contenu est stockée dans une base de données et accessible via une API (Application
Programming Interface) ou un service web qui permet aux développeurs de récupérer et
d’afficher le contenu à l’aide de n’importe quel framework ou technologie front-end de leur
choix.

Figure 2.2 – Architecture d’un CMS Headless

2.4 Étude de l’existant

Avant de commencer la création de n’importe quel projet, on doit passer par une phase
cruciale qui permet de déterminer les points faibles et les points forts des applications
existantes ce qui mène à la création d’une solution efficace et fiable. Dans cette section,
nous présentons une analyse de la solution existante.
2.5. Critique de l’existant 28

2.4.1 CMS Cockpit

CMSCockpit est un système de gestion de contenu (CMS), dont l’architecture est tra-
ditionnelle, qui est intégré à la plateforme de commerce électronique hybris de SAP. Il offre
une interface de gestion et de publication du contenu sur un site e-commerce hybris, avec
des fonctionnalités telles que :

— Création et gestion de pages de contenu.

— Gestion de catégories de produits et de fichiers.
— Intégration de contenu multimédia, y compris les images et les vidéos.
— Utilisation d’un éditeur WYSIWYG (What You SEE Is What You GET) pour la
création et la mise en page du contenu.
— Gestion de plusieurs langues et traductions de contenu.
Afin de bien éclaircir l’existant CMSCockpit ci-dessous une figure qui présente la confi-
guration d’un contenu de la plateforme CMSCockpit :

Figure 2.3 – Éditer un contenu dans le CMSCockpit

2.5 Critique de l’existant

Vu l’étude de l’existant, nous avons pu dégager quelques inconvénients fréquents qui se
présentent comme suit :
2.6. Objectifs de la solution envisagée 29

— Dépendance à hybris : CMS Cockpit est un outil qui est étroitement lié à hybris,
ce qui signifie que les mises à jour et les changements dans hybris peuvent affecter
la stabilité et la fonctionnalité du Cockpit.
— Faible évolutivité : Le CMS Cockpit peut avoir des difficultés en terme de la
gestion des grands contenus et d’extension, ce qui peut rendre difficile l’ajout de
nouvelles fonctionnalités ou l’adaptation aux besoins spécifique du client.
— Interface utilisateur peu conviviale : L’interface utilisateur du CMSCockpit
peut être considérée comme déroutante, puisqu’elle contient de nombreuses fonc-
tionnalités et options et qui peuvent ne pas être facilement accessible.
— Performance : Ce CMSCockpit peut avoir des problèmes de performance lors de la
gestion des grands volumes de contenu, ce qui peut entraîner des temps de réponse
plus longs et une expérience utilisateur médiocre.

2.6 Objectifs de la solution envisagée

Suites aux carences remarquées lors de la phase d’étude et de critique de l’existant, et
dans le cadre de ré-architecture de la plateforme Rubix, nous avons envisagé l’intégration
d’un CMS de type headless qui doit couvrir ces anomalies et qui peut répondre aux exi-
gences de notre solution. Parmi ces exigences que notre solution doit répondre on cite :

— Un CMS open source, qui offre une expérience utilisateur fluide et conviviale, tout
en simplifiant la modélisation du contenu.
— La solution doit faire preuve de la généricité des APIs, leur performance et scalabilité
dans un environnement international.
— Un CMS qui peut gérer des contenus du plusieurs pays et donc du contenu multi-
lingue.
— Un CMS qui prend en charge des différents types de la restriction.

2.7 Choix de la solution

Pour atteindre efficacement les objectifs de la solution, nous avons été confrontés à
un défi majeur consistant à trouver le CMS adéquat pour répondre aux besoins actuels
et futurs. Afin de relever ce défi avec succès, nous avons entrepris une étude comparative
approfondie entre les différents CMS de type headless. Le tableau 2.1 ci dessous récapitule
l’ensemble des CMS que nous avons rencontrés et testé, qui sont tous des CMS headless et
open source, ainsi que les avantages et les inconvénients de chacun.
2.7. Choix de la solution 30

CMS Avantages Inconvénients

- L’API GraphQL manque encore
- Personnalisation flexible et offre
Strapi de fonctionnalités par rapport à
une interface intuitive
l’API REST
- Offre une suite des APIs
- Installation de l’environnement
facile et configuration simple
- Facilite la collaboration entre
Contentful équipe grâce à des outils de la ges- - Documentation limitée
tion des workflow
- Nécessite un temps pour com-
prendre son fonctionnement
- Présence des fonctionnalités re- - Problèmes lors de l’installation de
Cockpit
quises son environnement
- Présence des fonctionnalités re-
[Link] - Interface peu conviviale
quises
- Bon support pour le multilin- - Difficulté lors de la gestion des
guisme APIs
- Ne supporte que les API de type
GraphCMS - Facile et simple à utiliser
GraphQL
- Offre une multiplicité des fonc- - Nécessite une compréhension plus
Craft CMS
tionnalités approfondie de son fonctionnement
- Ne supporte que les API de type
GraphQL
- Nécessite des connaissances dans
Directus - Multiplicité des fonctionnalités
la gestion des champs relationnels
- Modélisation de contenu simple et
facile
- Interface d’administration intui-
tive et user friendly
- Se présente comme une interface
graphique de base de donnée ce qui
facilite la mise en place de diverses
configurations

Table 2.1 – Comparaison des CMS

2.8. Étude comparative 31

2.8 Étude comparative

Après avoir examiné les différents CMS dans le tableau évoqué précédemment, il est
temps de se focaliser sur deux CMS spécifiques, Strapi et Directus. Ces deux outils ont
été choisis en raison de leur similarité et de leur pertinence pour répondre aux besoins
du projet. Une étude comparative détaillée et approfondie va être menée pour évaluer les
fonctionnalités, la performance et d’autres critères pertinents afin de déterminer le CMS
le plus appropriés pour le projet.

L’étude comparative se concentre sur la validation de la présence des plusieurs points,

tels que :

— Performance : Analyse des performances des deux CMS en termes de complexité

des APIs et de temps de réponse.
— La capacité de gérer un contenu de différentes langues.
— La gestion de visibilité de contenu (Restriction par groupe utilisateur, Restriction
temporelle).
— Fonctionnalités et flexibilité : Comparaison des fonctionnalités de base offertes par
Strapi et Directus, ainsi que leur capacité à être étendus ou personnalisés pour
répondre aux besoins spécifiques du projet.

2.8.1 Présentation des CMS

Avant de commencer la comparaison entre ces deux CMS, nous présentons Strapi et
Directus dans ce qui suit.

Strapi

Strapi est un système de gestion de contenu (CMS) basé sur [Link], un environne-
ment d’exécution JavaScript côté serveur. Il est écrit en utilisant le framework JavaScript
[Link], qui fournit une architecture web flexible et performante pour les applications
[Link]. Il utilise une API restful pour communiquer avec les applications tierces.

Directus

Directus est un CMS open-source basé sur [Link] et [Link]. Il adopte une approche
headless et fournit une interface d’administration intuitive. Directus permet de créer des
modèles de données personnalisés et offre une gestion avancée des fichiers et des actifs
2.8. Étude comparative 32

numériques. Il propose également des fonctionnalités d’authentification et d’autorisation,

ainsi qu’une documentation complète et une communauté active.

2.8.2 Performance
L’un des objectifs clés de notre solution est de disposer d’un CMS capable de fournir
des performances optimales, en offrant des API performantes et scalables, permettant des
requêtes rapides et une gestion aisée du contenu. Une expérience utilisateur fluide et un
temps de réponse rapide sont des éléments essentiels pour garantir l’efficacité globale du
site web.
Dans cette partie, nous examinerons les améliorations potentielles en termes de performance
que les CMS Strapi et Directus peuvent offrir, en mettant l’accent sur la complexité, rapi-
dité des requêtes et la facilité de gestion.

Aprés avoir crée une page avec des différents types de contenu tels que des champs de
texte, de type html, de média, ainsi que des champs relationnels de niveau supérieur et
les champs relationnels de second niveau. Nous avons pu accéder à ces données via des
requêtes APIs. Par la suite nous avons intégré ces APIs dans une application front-end
pour visualiser le rendu des deux pages. Aprés, nous avons évalué les performances à l’aide
de l’extension Lighthouse de Google. Les résultats de cette évaluation sont présentés dans
le tableau ci-dessous :

Figure 2.4 – Comparaison des performances

Comme conclusion, après avoir effectué une analyse comparative approfondie des APIs
2.8. Étude comparative 33

de Directus et de Strapi, il est possible de constater que les APIs de Directus présentent
plusieurs avantages par rapport à celles de Strapi.
Tout d’abord, les APIs de Directus sont plus simples et faciles à gérer. Leur structure est
intuitive et bien documentée, ce qui facilite leur utilisation et leur compréhension.
De plus, Directus offre une interface graphique conviviale pour la gestion des champs
relationnels, ce qui simplifie encore d’avantage le processus de configuration.

2.8.3 Gestion de la Restriction

La gestion de restriction, fait référence à la capacité de contrôler l’accès et la visibilité
du contenu dans les boutiques en ligne à travers un CMS. Elle permet de contrôler l’af-
fichage et l’accès aux produits, aux catégories, aux promotions et à d’autres éléments du
site en fonction de différents critères tels que l’identité de l’utilisateur, l’appartenance à
un groupe, la date de création d’un contenu, une période spécifique de temps, ou d’autres
attributs spécifiques..
Parmi les cas d’utilisation de la gestion de restriction dans les webshops on cite :

— Prix spécifiques aux groupes d’utilisateurs particuliers : Cela permet de

proposer des tarifs spéciaux aux clients B2B, aux membres VIP ou à d’autres seg-
ments de clients spécifiques.
— Gestion des promotions : La gestion de la visibilité dans un CMS inclut souvent
la possibilité de définir des promotions et de les rendre visibles pour les utilisateurs
cibles. Cela peut inclure des règles basées sur les totaux du panier, l’appartenance
à des groupes spécifiques, l’utilisation de codes promotionnels, etc.
— Restriction d’accès aux pages : Restreindre la possibilité d’accéder à des pages
ou fonctions spécifiques du Web Store. Ceci est utile pour les fonctionnalités qui ne
sont disponibles que pour les utilisateurs enregistrés, telles que les listes de souhaits,
les évaluations de produits, les options de personnalisation, etc.
Notre CMS doit être capable de fournir la possibilité de mettre en place deux types de
restriction : Restriction temporelle et Restriction par groupe d’utilisateurs.

Restriction par groupe d’utilisateurs

Cette fonctionnalité est disponible dans Directus et Strapi, bien qu’elles présentent des
différences dans sa mise en œuvre pour les deux CMS. Nous détaillons ces différences dans
le tableau ci-dessous :
2.8. Étude comparative 34

Figure 2.5 – Gestion de Restriction par groupe d’utilisateurs pour les deux CMS

Restriction temporelle

La gestion de publication de contenu, ou la restriction temporelle est une fonctionna-

lité qui doit être présente dans tous CMS. Elle permet de contrôler la disponibilité d’un
contenu, en limitant son accès à une période spécifique dans le temps.
Cette fonctionnalité revêt une grande importance, puisqu’elle offre aux propriétaires de
sites web la possibilité de gérer efficacement la visibilité et la disponibilité des contenus
promotionnels, des événements spéciaux, des articles saisonniers ainsi que d’autres infor-
mations sensibles au calendrier.

Pour les deux CMS, cette option est présente comme indiqué dans ci-dessous :
2.8. Étude comparative 35

Figure 2.6 – Gestion de la restriction temporelle pour les deux CMS

2.8.4 Gestion de contenu multilingue

Comme Rubix est une entreprise multinationale, et vu sa possession de plusieurs Web

stores, il est impératif de disposer d’un CMS capable de fournir un contenu multilingue.
Cette fonctionnalité permet une communication efficace avec un public international, per-
sonnalise l’expérience utilisateur, améliore le référencement et simplifie la gestion centrali-
sée du contenu dans différentes langues.
En effet l’internationalisation est implémentée de manière différente dans les deux CMS à
comparer :

Directus : La gestion de l’internationalisation nécessite une configuration manuelle. À

travers la création des champs relationnelles de type One To Many (O2M) avec la col-
lection des données "Langues", spécifique pour chaque page, pour permettre la prise en
charge des différentes langues.

Strapi : En ce qui concerne Strapi, la fonctionnalité d’internationalisation est dispo-

nible via un plug-in "i18n". Ce plug-in facilite l’internationalisation dans Strapi en offrant
des fonctionnalités prêtes à l’emploi.

2.8.5 Export/Import des données

Après l’intégration de nouveau CMS choisie, la tâche d’après, consiste à migrer les dif-
férents types de contenu de l’ancien outil Cockpit vers le nouveau. Cependant, il convient
de noter que cette tâche peut être difficile à réaliser sans disposer des outils ou des fonc-
tionnalités qui facilitent cette migration.

Cette fonctionnalité est présente dans les deux CMS. Pour Directus elle est faite à tra-
vers un simple clique sur l’interface de création de contenu, ce qui engendre une migration
simple et facile, comme indiqué dans la figure 2.8, de plus cette fonctionnalité peut aider
2.8. Étude comparative 36

à importer toute la liste des IDs des groupes des utilisateurs.

Figure 2.7 – Export/Import en Directus

Par contre pour Strapi, la possibilité d’importer et d’exporter des contenus est faisable
en utilisant des commandes basées sur CLI (Command Line Interface) comme indiqué
ci-dessous :

Figure 2.8 – Export/Import en Strapi

2.8.6 Choix de l’outil CMS

Après avoir évalué les différents outils de CMS disponibles, en prenant en compte nos
besoins spécifiques. Ainsi suite à la comparaison faite entre Strapi et Directus en fonction
de leurs similitudes et de leur compatibilité avec nos exigences fonctionnelles, voici un
tableau récapitulatif de l’étude comparative réalisée :
Pour conclure et après une évaluation approfondie, nous avons finalement adopté
Directus comme solution qui répond à nos besoins actuels et futurs. Directus offre des
2.9. Conclusion 37

Table 2.2 – Comparaison entre Strapi et Directus

Critères Strapi Directus

API Des requêtes complexes Simple et performante
Interface utilisateur Conviviale Conviviale
Restriction par groupe Seulement par filtre sur la
Par filtre sur la requête
d’utilisateur requête
Génére une liste des IDs des
groupes d’utilisateurs
Configuration directe sur
Restriction temporelle Par filtre sur la requête
l’interface d’administration
Configuration manuelle
Multilingue Plug-in i18n disponible
avec les champs relationnels
Directement sur l’interface
Export/Import Par des commandes CLI
d’administration
Coût 99.00 $US/mois 25 $US/mois

nombreuses services qui correspondent parfaitement aux exigences de notre projet.

Ces services incluent la gestion des restrictions de contenu, ce qui est essentiel pour notre
projet. De plus, la prise en charge du contenu multilingue répond parfaitement à la nature
multinationale de Rubix.
Une autre caractéristique est la suite d’API performantes et robustes proposées par Di-
rectus. Cela nous permettra d’intégrer facilement notre CMS avec d’autres systèmes et
applications, offrant ainsi une plus grande flexibilité et une meilleure interopérabilité.

2.9 Conclusion
Dans ce chapitre, nous avons détaillé les concepts qui entourent notre projet. Nous
avons présenté l’e-commerce et la plateforme hybris, ainsi que les systèmes de gestion de
contenu associés. Par la suite, nous avons défini la problématique et les objectifs du projet,
qui résument la mise en place d’un CMS headless. Nous avons ensuite effectué une étude
comparative approfondie et détaillée entre deux CMS pertinents, qui nous a permis à la
fin de prendre une décision éclairée pour choisir le CMS final qui répondra le mieux à nos
besoins spécifiques.
Chapitre 3

Analyse & spécification des besoins

Après l’étude préalable, ce chapitre entame par la spécification et l’analyse des besoins.
Le but donc, c’est d’identifier les différents acteurs et d’analyser les besoins fonctionnels et
non fonctionnels. Ces besoins seront exprimés par la suite sous forme des diagrammes de
cas d’utilisation.

3.1 Identification des acteurs

Tout au long de la période de documentation et de recherche, nous avons pu distinguer

les trois acteurs potentiels qui peuvent interagir avec notre système à développer :
— Administrateur Il est l’acteur ayant tous les droits d’accès. Il gère la partie back
end du site, et la partie CMS.
— Client C’est un acteur ayant un compte pour accéder aux webshops, qui peut
visualiser du contenu.
— Acteur systéme : CMS Directus C’est l’outil de gestion de contenu qui offre
l’interface de création des différents types de contenu.

3.2 Spécification des besoins

La satisfaction de tous les besoins de projet est une condition essentielle pour la mise en
œuvre réussie du système. Cette section se concentre donc, sur l’identification des besoins
fonctionnels et non fonctionnels.

38
3.2. Spécification des besoins 39

3.2.1 Besoins fonctionnels

Les besoins fonctionnels spécifient les exigences de chaque acteur auxquels le système
à développer doit nécessairement répondre. Afin de mieux clarifier les choses, le tableau
suivant met l’accent sur les différents besoins fonctionnels dégagés pour chaque acteur du
site :

Acteur Fonction
Administrateur technique
qui a accès à toutes les fonctionnalités du Backend.
S’authentifier à son compte
Gérer les utilisateurs
Gérer les groupes d’utilisateurs
L’administrateur
Se connecter sur le CMS
Créer et configurer des différents types des contenus sur le CMS.
Gérer les types de contenu
Modifier, Activer, Désactiver un contenu
Visualiser des contenus
Fournir les interfaces et les fonctionnalités de création de contenu.
Gérer la visibilité de contenu
Le CMS Directus Gérer plusieurs Webshops
Fournir du contenu multimédia, des articles, des carrousels
de produits, des carrousels des images, etc.
Naviguer sur le site et consulter des contenus en mode anonyme
Le Client S’authentifier à son compte
Demander une page de contenu personnalisée.

Table 3.1 – Acteurs en interaction avec le système

3.3. Diagrammes des cas d’utilisation 40

3.2.2 Besoins non fonctionnels

Les besoins non fonctionnels présentent les contraintes et les considérations qui doivent
être prises en compte lors de la conception et de la réalisation d’un système, afin d’assurer
son bon fonctionnement et de fournir une meilleure expérience client. Dans notre cas, nous
avons identifié les principales restrictions que notre solution doit respecter, à savoir :

— Performance : Le site doit être performant et robuste, c’est à dire l’accès au

contenu de CMS doit être rapide de façon qu’il doive optimiser les traitements pour
avoir un temps de réponse assez faible.
— Sécurité : Les APIs de notre solution seront sécurisées et contrôlées par des tokens
et des cookies.
— Maintenance : Le code doit être lisible, commenté et structuré pour faciliter la
tâche de maintenance et pour que le module de gestion des restrictions soit extensible
afin d’assurer la possibilité d’évoluer par rapport aux besoins de projet.
— Compatibilité : Notre solution doit être conforme aux normes et à l’architecture
établies par Rubix.

3.3 Diagrammes des cas d’utilisation

Dans ce paragraphe, nous présentons les différents diagrammes de cas d’utilisation qui
nous permettent de structurer les besoins des utilisateurs et les objectifs du système visant
à atteindre.

3.3.1 Diagramme de cas d’utilisation général :

La figure ci-dessous représente le diagramme de cas d’utilisation général de l’application
web, mettant en valeur les fonctionnalités principales du système et les interactions entre
ce dernier et les différents acteurs.
3.3. Diagrammes des cas d’utilisation 41

Figure 3.1 – Diagramme de cas d’utilisation général

Afin de mieux expliquer et identifier les besoins de notre système, nous allons détailler
le diagramme de cas d’utilisation global en le décomposant en des sous diagrammes de cas
d’utilisation par acteur.

Raffinement de cas d’utilisation "Gérer et Configurer contenu" de l’adminis-

trateur

Après avoir connecté au CMS, l’administrateur permet de configurer plusieurs types de

contenus ; soit créer des nouveaux pages ou créer des composants, ce qui signifie la relation
d’extension. En créant un nouveau composant, il peut accéder à ce dernier et le modifier,
l’activer ou le désactiver. Ces notions sont modélisée par des relations d’extension « extends
» avec créer un nouveau composant. La même chose pour configurer une page.
La figure ci-dessous, présente le diagramme de cas d’utilisation « Gérer et configurer un
contenu ».
3.3. Diagrammes des cas d’utilisation 42

Figure 3.2 – Diagramme de cas d’utilisation de configurer le Contenu

Raffinement de deux cas d’utilisation "Gérer les utilisateurs" et "Gérer les

groupes d’utilisateurs" de l’administrateur

Comme l’administrateur possède l’accès à toutes les fonctionnalités du backend du site,

en se connectant à l’interface HMC de hybris, il aura donc le droit de gérer les groupes
des utilisateurs, ou il peut ajouter un nouveau groupe, en lui attribuant un nom et un id.
Cette notion est modélisée par une relation d’extension.
D’autre part il peut de la même façon gérer des utilisateurs en créant un nouveau utilisateur.
Il peut aussi attacher un groupe d’utilisateurs à un utilisateur crée, ce qui explique la
relation de "extends" entre "gérer les utilisateurs" et les autres cas.
La figure 3.3, projette ces deux cas d’utilisations.
3.3. Diagrammes des cas d’utilisation 43

Figure 3.3 – Diagramme de deux cas d’utilisation "Gérer les utilisateurs et les groupes
d’utilisateurs"

Raffinement de cas d’utilisation "Visualiser contenu sur le site" du Client

Le client, comme étant un navigateur ne disposant pas de compte peut consulter de

contenu sur le webshop, visible pour tout le monde. En outre il peut consulter des pages
personnalisées, sous la condition d’être authentifié sur la plateforme Rubix. Ce principe est
modélisé à travers une relation d’inclusion « includes » entre le cas d’utilisation « Visualiser
un contenu personnalisé » avec « S’authentifier » comme illustré dans la figure 3.4.

Figure 3.4 – Diagramme de cas d’utilisation "Visualiser le contenu" de client

• Raffinement de cas d’utilisation "Visualiser un contenu personnalisée" :

— Objectif : Permet aux utilisateurs connectés de consulter une page ou des com-
posants spécifiques, selon leurs informations.
3.4. Conclusion 44

— Acteur : Client
— Pré-condition : L’acteur se connecte au système.
— Scénario nominal :
1. L’acteur saisit son login et son mot de passe.
2. Le système vérifie les informations saisies.
3. Le système trouve que les informations saisies sont valides.
4. Le système vérifie l’id de groupe d’utilisateur auquel le client appartient.
5. Le système connecte l’acteur à son espace, et lui récupère le contenu spéci-
fique.
— Scénario d’erreur :
1. L’acteur saisit son login et son mot de passe.
2. Le système vérifie les informations saisies.
3. Le système trouve que les informations saisies sont invalides.
4. Retourner vers l’étape n°1.

3.4 Conclusion
Ce chapitre a été consacré à l’analyse et la spécification des besoins du projet. Les
besoins ont été énumérés, les acteurs et les cas d’utilisations ont été dégagés. Ensuite, les
diagrammes des cas d’utilisation correspondants ont été tracés et raffinés par le traitement
de quelques enchaînements.
Chapitre 4

Étude Conceptuelle

Après avoir décortiqué les besoins des utilisateurs, dans cette partie une étude concep-
tuelle va être entamée, elle constitue l’avant dernier volet de ce rapport et il a pour objectif
de présenter les différentes étapes de conception de l’application. Pour cela, la conception
va être détaillée à travers les diagrammes UML.

4.1 Conception globale

En reconnaissant son importance fondamentale, cette section se concentre sur la concep-
tion architecturale de notre solution. Nous débutons en clarifiant les deux aspects essentiels
de cette conception : l’architecture physique et l’architecture logique.

4.1.1 Architecture Physique

Afin de garantir une cohérence entre l’architecture logique et l’architecture physique,
ainsi que pour positionner efficacement les différentes couches de notre solution, nous avons
opté pour l’utilisation de l’architecture 3-tiers.
L’architecture 3-tiers est une approche de conception qui sépare notre solution en trois
couches distinctes : la couche de présentation, la couche de traitement et la couche de don-
nées. Cette division permet une meilleure modularité, évolutivité et facilité de maintenance
de notre système.
Cette architecture est représentée dans le diagramme de déploiement ci-dessous :

45
4.1. Conception globale 46

Figure 4.1 – Architecture physique de la solution

• Pc Utilisateur : C’est un tier qui représente la couche présentation et qui corres-

pond à l’interaction avec l’utilisateur qui va utiliser l’application via un navigateur
Web.
• Serveur Web : Comprend le serveur d’application front end, qui est en interaction
directe avec le backend du système pour récupérer les informations des utilisateurs,
dans le but de permettre la récupération du contenu auprès du composant CMS
en fonction des données récupérées, ce qui explique la connexion du front avec ce
dernier.
• Serveur BD : Correspond à la couche d’accès aux données liée au serveur de base
de données (SGBD), dans notre cas MySQL.

Choix de cette architecture

Au cours de la période de recherche, nous avons rencontré deux approches architectu-

rales différentes concernant la récupération du contenu à partir du CMS.
- La première approche : Le front-end fait directement appel au CMS pour récupérer
le contenu.
- La deuxième approche : c’est le back-end qui récupère le contenu du CMS et le trans-
met ensuite au front-end pour avoir le rendu.
Après avoir examiné attentivement ces deux approches, nous avons choisi la première op-
tion où le front-end appelle directement le CMS pour récupérer le contenu. Cette décision
a été prise en raison de plusieurs avantages qu’elle offre.

En fait en adoptant cette approche :

• Nous éliminons une couche intermédiaire entre le front-end et le CMS, ce qui sim-
4.1. Conception globale 47

plifie l’architecture et réduit la complexité du système.

• Permet également de réduire le temps de traitement des requêtes, car le front-end
peut accéder directement au contenu souhaité sans passer par une autre couche
intermédiaire.

4.1.2 Architecture logique

Notre solution est basée sur la plateforme hybris, qui adopte l’architecture à trois
couches comme architecture logique.
Pour décrire l’architecture logique de notre système de manière claire, nous avons choisi
d’utiliser un diagramme de packages. Ce diagramme schématisé dans la figure 4.5 nous
permet de présenter la hiérarchie des différentes couches de notre système en montrant les
interactions entre les différents packages.

Figure 4.2 – Architecture logique de la solution

Notre système est composé de trois couches essentielles comme indiqué dans la figure
ci-dessus :
• Couche de données : La couche en question inclut le paquetage "Modèle", qui
contient les classes représentant les entités de la base de données Hybris, ainsi que
le paquetage "DAO" (Data Access Object), qui définit les classes permettant l’ac-
cès aux données du système. En utilisant DAO, il est possible de s’abstraire de la
4.1. Conception globale 48

manière dont les données sont stockées au niveau des objets métiers.

• Couche Traitement : Elle représente la partie fonctionnelle et logique du système

qui permet l’interaction avec la couche de présentation et la couche de données. Elle
comprend les sous-couches de service, de façade et de mapper.
— Paquetage Service : Cette couche implémente des classes de niveau supérieur
à celles des DAO et sert d’intermédiaire entre cette dernière et la couche de
façade. Elle met en œuvre la logique métier et décrit les opérations effectuées
sur les données en fonction des requêtes des utilisateurs.
— Paquetage Façade : Cette couche se situe à un niveau supérieur à celui du Service
et utilise le paquetage Service.
— Paquetage Mapper : Ce paquetage est directement utilisé par le contrôleur qui
appartient à la couche de présentation et qui fait appel au paquetage Façade
décrit précédemment. Il comprend le paquetage Entité qui représente les enti-
tés nécessaires pour l’appel du contrôleur, ainsi que le paquetage Populator qui
permet de convertir les modèles en ces entités pour répondre à notre besoin.

• Couche Présentation : C’est la dernière couche qui implémente les interfaces

assurant la communication directe avec l’utilisateur. Les interfaces implémentées
sont :
— Frontend : C’est le paquetage contenant l’implémentation de la partie frontend
de notre solution en React Typescript.
— Contrôleur (Controller) : C’est le paquetage représentant la couche d’interaction
d’internaute avec le site e-commerce.
— HMC : C’est l’abréviation de « Hybris Management Console » qui représente
une vue centrale de la suite Hybris, configurée dans le fichier ”[Link]” d’un
poste et permet d’afficher les éléments existants dans le fichier ”[Link]”. C’est
un outil destiné à l’équipe informatique et aux développeurs en leurs of- frant
la possibilité de gérer les fonctionnalités de l’Hybris Commerce Suite tels que
produits, promotions, commandes. . .
— Cockpits : Il offre un grand nombre de composants hautement configurables, qui
peuvent être utilisés pour créer une interface utilisateur graphique (GUI) pour
prendre en charge des cas d’utilisation commerciale de haut niveau. Cela permet
aux utilisateurs d’effectuer toutes leurs tâches courantes rapidement et intuiti-
vement. Le cadre Hybris Cockpit [8] complète les fonctionnalités offertes par la
console de gestion Hybris (HMC), qui fournit un contrôle de niveau inférieur sur
toutes les données du système Hybris.
4.1. Conception globale 49

4.1.3 Architecture Logique : Côté client

L’architecture côté client de notre application suit le modèle REDUX, tel qu’illustré
dans la figure 4.3. REDUX est une architecture spécialement conçue pour les applications
Web, offrant une solution robuste pour la gestion de l’état de l’application. Elle repose
sur le concept de "store" (magasin), qui agit comme un référentiel centralisé de données
stockant l’état et les informations de tous les composants de l’application.
En s’abonnant au store, chaque composant peut surveiller les changements de l’état et
y réagir. Lorsque des modifications sont apportées à l’état, les composants sont notifiés
et peuvent se mettre à jour en conséquence. Ce qui facilite la gestion des données et
la communication entre les différents composants. Cela permet également d’améliorer les
performances en évitant les redondances et en optimisant les mises à jour de l’interface
utilisateur.

Figure 4.3 – Architecture logique : Architecture Redux

Dans la paragraphe ci-dessous, nous clarifions les différentes couches qui prennent en
charge la fonctionnalité de l’architecture Redux.
• Action : Les actions dans Redux sont des objets JavaScript qui décrivent un type
d’événement ou une intention de modification de l’état de l’application. Elles sont
créées par des fonctions appelées "action creators" et sont envoyées au store. Les
actions contiennent généralement un type (une chaîne qui identifie l’action) et des
données supplémentaires nécessaires pour effectuer la modification de l’état.

• Middlewares : Le middleware dans Redux est une couche facultative qui se place
entre l’envoi d’une action et le traitement par les reducers. Il permet d’effectuer
des tâches supplémentaires telles que la journalisation des actions, la gestion des
appels asynchrones, ou la transformation des actions avant qu’elles n’atteignent les
reducers. Les middlewares sont ajoutés au store lors de sa création à l’aide de la
4.1. Conception globale 50

fonction "applyMiddleware".

• Store : Le store est l’objet central de Redux. Il contient l’état global de l’appli-
cation et gère la logique de mise à jour de cet état. Le store est créé en utilisant
une fonction appelée "createStore", qui prend en argument les reducers et éventuel-
lement des middlewares. Le store a plusieurs méthodes, dont les plus importantes
sont "getState" pour accéder à l’état actuel, "dispatch" pour envoyer des actions et
"subscribe" pour s’abonner aux changements de l’état.

• Reducers : Les reducers sont des fonctions pures qui spécifient comment l’état de
l’application est modifié en réponse à une action. Ils prennent en entrée l’état actuel
et une action, et retournent un nouvel état. Chaque reducer est responsable d’une
partie spécifique de l’état et ne doit pas modifier directement l’état existant, mais
plutôt retourner une nouvelle copie de l’état modifié.

4.1.4 Structure : Côté Client

Le schéma du package, tel qu’illustré dans la Figure 4.4, offre une vue d’ensemble de
l’architecture du système côté client et de l’organisation de ses composants en packages.
Il permet de visualiser comment les différents modules et fonctionnalités sont regroupés et
interagissent les uns avec les autres.
4.1. Conception globale 51

Figure 4.4 – Diagramme de package : Côté client

Cette partie comprend plusieurs éléments essentiels qui contribuent à sa fonctionnalité

et son structure.
• Au centre de notre architecture, se trouve le fichier de configuration "_com-
[Link]", qui joue un rôle essentiel dans la définition des tracés et des routes
de notre application. Ce fichier de configuration joue un rôle pivot en nous permet-
tant d’organiser efficacement notre projet.
• Au sein de notre projet, la page qui joue un rôle trés important dans l’exposition du
contenu du CMS aux utilisateurs. La page "[Link] est soigneusement
composée de plusieurs composants. Ces composants, réutilisables qui contribuent à
la modularité et à l’évolutivité de notre interface utilisateur.
• Dans le package Components qui contient les différents composants qui formule
notre solution. Ces derniers sont appelés par la page ContentPage. On a quatre sous
packages qu’on va les citer dans la ce qui suit.

— CMSComponent Ce package, contient les composants qui sont responsable de

l’affichage de contenu du CMS (des textes, des carrousels des images, des images,
les langues, etc).
— ProductCarrousel Pour qu’on puisse exposer les carrousels des produits, la
page ContentPage fait appel à ce package, qui à son tour inclut des composants
spécifiques.
4.2. Conception Statique 52

— Footer & Header deux packages qui ont le rôle d’afficher la section footer ainsi
que la section header de la page ContentPage.

• Enfin, nous avons le store Redux, un élément fondamental de notre application.

Redux sert de référentiel centralisé pour la gestion l’état global de notre projet. Il fa-
cilite la coordination et la communication entre les différentes pages et composants,
assurant la cohérence du projet. Dans ce package, on a le Thunk qui tire partie de
package Domain, qui fait l’appel aux différents APIs pour récupérer les informa-
tions nécessaires pour affichage, assurant une expérience utilisateur dynamique et à
jour.

4.2 Conception Statique

La conception statique que nous la présentons avec un diagramme de classe, est une
étape essentielle de la planification et de la visualisation de la structure et des relations des
objets dans un système logiciel, fournissant ainsi une base solide pour le développement
ultérieur du code.

4.2.1 Diagramme de classe

Le diagramme de classe ci-dessous présente les différentes interfaces et classes liées entre
eux, qui interviennent pour la récupération des informations de l’utilisateur connecté au
système.
4.2. Conception Statique 53

Figure 4.5 – Diagramme de classe

Dans ce qui suit, nous clarifions ce diagramme présenté dans la figure ci-dessous :
— Le paquet Controller : contient la classe “UserRestController” : qui implémente
les méthodes qui permettent de retourner les informations de l’utilisateur aux fron-
tend pour qu’il puisse appelle le contenu du cms.
— Le paquet Mapper : Le contrôleur utilise ce paquet, qui contient l’interface “Use-
rInfoRestMapper” implémentée par la classe “DefaultUserInfoRestMapper” et qui
fait appel au “CustomerFacade” et “UserService”.
— Le paquet Populator : Contient les classes qui permettent de convertir un modèle
en une entité et vice versa pour se focaliser que sur les données que nous avons
réellement besoin dans le front tel que “UserV1RestPopulator”, ou nous avons ajouté
la méthode “fillCmsRestriction” permettant de retourner la liste des groupes des
utilisateurs, ayant le prefixe "cms", dans le but d’éviter de retourner tous les groupes
attachés à cet utilisateur.
— Le paquet Entities : La classe ”UserInfoRestEntity” : représente le type retourné
par l’api ”getUsers”.

4.2.2 Documentation de l’API : GetUser

Après avoir précisé les champs nécessaires pour définir un utilisateur connecté qui va
être consommé par le frontend, afin de récupérer le contenu en répondant au besoin de la
restriction. Nous présentons donc notre API ayant comme type ”GET” qui va retourner les
4.3. Conception dynamique 54

différentes informations de type json, qui sont liées à l’utilisateur, et surtout les groupes des
utilisateurs ayant le préfixe "cms" aux quels il appartient. La figure 4.6 montre le retour
de l’api GetUser.

Figure 4.6 – API GetUser

4.3 Conception dynamique

Pour la conception dynamique, nous optons pour le diagramme de séquence Objet.

4.4 Diagramme de séquence

Afin de bien illustrer l’interaction entre les composants et les instances de notre système,
nous présentons le diagramme de séquence illustré dans la figure 4.7 qui montre le processus
pour exposer un contenu du CMS sur le front.
4.4. Diagramme de séquence 55

Figure 4.7 – Diagramme de séquence

4.5. Conclusion 56

- Lorsque le client demande une page spécifique sur le webshop, si le client n’est pas
connecté sur son compte, le front lui envoie la page d’authentification. En cas ou l’authenti-
fication n’est pas validé le formulaire sera renvoyé vers le client, sinon dans le cas de succès
un token va être généré en retournant l’Id fonctionnel de l’utilisateur.
- À travers cet Id retourné, le contrôleur peut récupérer les informations de client (id,
UserGroups attaché à l’utilisateur) et les renvoyer vers le front.
- Finalement à l’aide des informations récupérées, le front fait appel au CMS pour avoir le
contenu spécifique à l’utilisateur.

4.5 Conclusion
Ce chapitre présente une vue conceptuelle de la solution à mettre en place. Nous avons
exposé les différents diagrammes UML pour mieux comprendre les fonctionnalités offertes
et pour mieux représenter la communication entre les différents objets du projet. Le chapitre
suivant, présente la partie mise en œuvre de l’application.
Chapitre 5

Mise en oeuvre de la solution

La phase qui suit une conception bien détaillée, est la phase de réalisation de projet.
Ce chapitre présente le résultat du travail effectué durant ce projet de fin d’étude, où nous
allons illustrer brièvement les environnements logiciels de développement, puis nous allons
détailler les étapes de configuration de contenu. Enfin, nous finissons par mettre en valeur
les différentes interfaces décrivant les fonctionnalités de notre projet. Nous clôturons ce
chapitre par une évaluation des performances de notre solution.

5.1 Environnement de développement

L’environnement de développement est constitué par deux parties nommées environne-
ment matériel, et environnement logiciel.

5.1.1 Environnement matériel

Afin d’assurer une exécution fluide de l’application et un processus de travail efficace,
nous avons utilisé un ordinateur de bureau DELL doté des caractéristiques suivantes :

Table 5.1 – les caractéristiques de l’ordinateur utilisé

Caractéristiques Valeur
Marque DELL
Processeur Intel Core i7
Mémoire RAM 32 GO
Stockage 1 TO
Système d’exploitation Windows 10 professionnel

57
5.1. Environnement de développement 58

5.1.2 Environnement Web

Dans ce paragraphe nous allons aborder les langages et logiciels web dont nous avons
eu besoin pour pouvoir développer, effectuer des tests et valider notre projet.

Docker

Docker est une plateforme open-source qui permet de créer, déployer et exécuter des
applications de manière isolée dans des conteneurs [9].

Java Entreprise Edition

Java EE est l’acronyme de ”Java Enterprise Edition”. C’est une spécification pour la
plate-forme Java d’Oracle. Elle est construite sur le langage Java et la plateforme Java
SE (java Standard Edition). Cette plateforme est destinée aux applications d’entreprises
pour la création d’application web. Son objectif est de fournir une API des architectures
distribuées et multitiers. De plus, elle permet de développer des solutions déployées et
exécutées sur un serveur d’ap- plications [10].

Framework Spring

Le framework Spring open source permet de construire et de définir l’infrastructure

d’une application java3 dont il facilite le développement et les tests. Le framework Spring est
connue par ses fonctionnalités de programmation orientée vers l’aspect (AOP) et d’inversion
de contrôle qui garantit l’injection de dépendance (DI) et la recherche de dépendance De
plus, ce framework se base sur l’intégration de concept de la couche d’abstraction qui
consiste à intégrer facilement d’autres frameworks et d’autres bibliothèques [11].

React

React est une bibliothèque JavaScript open-source développée par Facebook. Elle per-
met de construire des interfaces utilisateur dynamiques et réactives en utilisant des com-
posants réutilisables. React utilise une approche basée sur la déclaration de composants,
où chaque composant représente une partie de l’interface utilisateur et gère son propre état
et son rendu [12].

Typescript

TypeScript, est un langage de programmation open-source développé par Microsoft. Il

s’agit d’une extension de JavaScript qui ajoute des fonctionnalités de typage statique au
5.2. Réalisation 59

langage. TypeScript permet de détecter et d’éviter les erreurs courantes dès la phase de
développement, en fournissant un système de types robuste et en offrant des fonctionnalités
avancées telles que l’auto-complétion, la vérification statique et la documentation améliorée
[13].

Bibliothèque Redux

Redux est une bibliothèque open-source pour la gestion d’état dans les applications
JavaScript. Permet la gestion centralisée de l’état global de l’application [14].

5.1.3 Environnement logiciel

Les principaux outils que nous avons utilisés pour le développement, ainsi que les tests
de notre site sont :

Eclipse IDE for Java EE Developers

Eclipse IDE (Integrated Development Environment) est un environnement de déve-

loppement intégré open-source utilisé principalement pour la programmation dans divers
langages, notamment Java, C/C++, Python, PHP et bien d’autres. Il fournit un ensemble
d’outils et de fonctionnalités pour faciliter le développement de logiciels [15].

Intellij

IntelliJ est un environnement de développement intégré destiné au développement de

logiciels informatiques reposant sur la technologie Java [16].

Postman

Pour interroger ou tester nos web services et API. « Postman » est un logiciel qui
propose de nombreuses fonctionnalités, une prise en main rapide et une interface graphique
agréable. Il permet d’envoyer toutes sortes de requêtes et les personnaliser très finement
[17].

5.2 Réalisation
Après avoir préparé l’environnement du travail, nous nous intéressons à l’implémen-
tation qui représente l’objectif de ce chapitre qui se décompose en trois parties. Nous
5.2. Réalisation 60

exposons en premier lieu les configuration faites au niveau du CMS, après nous montrons
les différents interfaces de notre solution. Nous finissons par une évaluation pertinente des
performances de la solution.

5.2.1 Configuration du contenu sur le CMS

Comme nous l’avons expliqué dans les parties précédentes, Directus est un système de
gestion de contenu permet de gérer les différents types de contenu créés par l’administra-
teur. Dans cette partie nous allons éclaircir, la façon dont le contenu est crée en se basant
sur des captures d’écran.

Connexion sur le CMS par l’administrateur

Pour accéder à l’interface de configuration du contenu du CMS, l’administrateur doit

se connecter en remplissant le formulaire d’authentification présenté dans la figure 5.1

Figure 5.1 – Interface de la connexion sur le CMS

Création de collection des données

Puisque Directus se présente comme une interface graphique d’une base de donnée,
donc cela permet de créer le contenu comme des modèles de données en première étape.
Ci dessous la figure montrant l’interface de création d’une nouvelle collection de données
de type page :
5.2. Réalisation 61

Figure 5.2 – Interface de création d’une nouvelle page

L’ajout des différents champs

La page illustrée dans la figure 5.3 a plusieurs champs, tels que :

Figure 5.3 – Les champs configurées pour une page

— Contenu : de type code Html, peut contenir des paragraphes, du texte, etc.
— Images : Une multiplicité des images ou un carrousel des images de type Files.
— langue_id : Spécifie l’id de la langue de contenu.
— Visible : C’est un champ booléen pour indiquer si la restriction est appliquée sur
cette page ou pas.
5.2. Réalisation 62

— Restriction : Spécifie les Ids des groupes d’utilisateurs qui sont autorisé à visualiser
cette page.
— Restriction inversée : Spécifie les Ids de groupe d’utilisateur qui ne sont pas
autorisé à visualiser cette page.
-Ajout d’un champ : Carrousel des images

Figure 5.4 – Ajout des carrousels des images sur la page

Configuration de la restriction par groupe d’utilisateur

Pour mieux comprendre, comment la restriction est gérée dans le CMS, et comme on a
dit que avec Directus, on a pu générer une liste des Ids des groupes d’utilisateurs grâce au
champ relationnel de type Many to Many avec la collection usergroups. Les figures 5.5,
5.6, et 5.7 suivantes montrent la façon dont la restriction est implantée :
- La collection des IDs des groupes des utilisateurs
5.2. Réalisation 63

Figure 5.5 – La liste des IDs des groupes des utilisateurs

- L’ajout du champ restriction dans une page

Figure 5.6 – L’ajout du champ restriction dans une page

-Génération de la liste des IDs en configurant la page, et pour ajouter les IDs des
groupes des utilisateurs qui sont autorisées à voir le contenu, on clique sur le bouton "Add
Existing", pour récupérer la liste et choisir les IDs.
5.2. Réalisation 64

Figure 5.7 – La récupération de la liste des IDs

Configuration d’un composant de type carrousel des produits

Les carrousels des produits dans un site d’e-commerce sont des éléments qui doivent
être toujours présents.
Pour gérer ce type de composant, nous avons crée tout d’abord une collection des listes
des produits ayant deux champs, comme illustré dans la figure 5.8 :
— Code produit : c’est un champ de type chaîne
— Label : C’est un champ de type chaîne, contenant le nom du produit

Figure 5.8 – Liste des produits

Aprés avoir crée cette liste, nous avons configuré un composant nommé Carrousel,
possédant les champs suivants, comme indiqué dans la figure ci-dessous :
— Titre : Champ de type chaîne, contenant le titre de composant.
5.2. Réalisation 65

— Produits : Champ relationnel de type ManyToMany avec la collection Liste produits,

pour récupérer les codes produits.

Figure 5.9 – Composant Carrousel des produits

5.2.2 Exposition du contenu configuré sur le Webshop

Maintenant, le contenu est bien préparé, il est le temps d’exposer et d’intégrer ces
composants et ces pages sur notre webshop, tout en prenant en compte tous les cas de test
et les différents scénarios possibles de gestion de la restriction.

Ajouter des nouveaux groupes des utilisateurs

L’administrateur de site prend en charge la gestion des groupes des utilisateurs et des
différents clients du site.
Pour cela aprés que l’administrateur se connecte à la plateforme HMC, il va procédé tout
d’abord par ajouter un nouveau groupe d’utilisateur. Ce cas est présenté dans la figure
5.10
5.2. Réalisation 66

Figure 5.10 – Ajouter un nouveau groupe d’utilisateur

Après, il doit l’attacher à un client nommé "[Link]", comme montré dans

la figure 5.11.

Figure 5.11 – Attacher ce groupe à un client

Affichage de la page Orexad Brammer

La page crée précédemment, va être affichée sur le webshop. Cette page est accessible
que pour l’utilisateur [Link], ou on a définit la restriction sur cette page
5.2. Réalisation 67

au groupe d’utilisateur "_cms_content" au lequel appartient l’utilisateur, comme indiqué

dans la figure 5.12. Ainsi il doit se connecter pour la visualiser.

Figure 5.12 – Définir la restriction sur la page

-Scénario 1 : Si l’utilisateur "[Link]" est connecté et veut accéder à cette

page, la page 404 sera affiché. La figure ci-dessous confirme ce scénario.

Figure 5.13 – Page introuvable, dans le cas le client est [Link]

-Scénario 2 : L’utilisateur "[Link]" se connecte à son compte, en entrant

un login et un mot de passe non valides. la figure ci dessous présente le message affiché
dans ce cas :
5.2. Réalisation 68

Figure 5.14 – Connexion échoué

-Scénario 3 : L’utilisateur est bien connecté à son compte, après il demande la page
en tapant l’url correspondant, et la page est bien affiché dans la figure 5.15, contenant à la
fin un carrousel des images (figure 5.16).

Figure 5.15 – Affichage de la page

5.2. Réalisation 69

Figure 5.16 – Carrousel des images

Affichage de la page Selection des Avantages Gigaphones

Cette page définit différents types de composant personnalisés selon le groupe des uti-
lisateurs mentionné. En fait c’est une page de promotion, c’est pour cela il est nécessaire
de personnaliser son affichage. Sur le CMS, la page est présentée comme indiqué dans la
figure 5.17.

Figure 5.17 – la page Selection des Avantages Gigaphones sur CMS

- Scénario 1 : Cette page contient quatre composants ou la restriction est appliquée,

et un autre composant "Mention légales", qui est un composant visible pour tout le monde,
connecté ou non. Dans la figure 5.18, l’utilisateur en mode anonyme, en accédant à l’url
de cette page, le composant visible pour tous le monde est affiché :
5.2. Réalisation 70

Figure 5.18 – Composant visible pour tous le monde

- Scénario 2 : Après nous allons prendre deux composants, l’un n’est visible que pour
l’utilisateur "[Link]" et l’autre est visible que pour "[Link]".
Tout d’abord le client "[Link]" se connecte, sur l’interface présenté dans la
figure 5.19.

Figure 5.19 – Connexion de l’utilisateur [Link]

Dés qu’il se connecte la page personnalisée est bien affichée, comme le montre la figure
5.20.
5.2. Réalisation 71

Figure 5.20 – Pour l’utilisateur [Link]

La figure ci-dessous, montre le résultat d’affichage de la page pour l’utilisateur "[Link]" :

Figure 5.21 – Pour l’utilisateur [Link]

Configuration et Affichage d’un contenu multilingue

Sur le CMS , on a arrivé a configurer un contenu avec des différentes langues, pour
chaque page, on lui ajoute un champ relationnel de type OneToMany avec la collection
langues. Cette relation est modélisée dans la figure 5.22.
5.2. Réalisation 72

Figure 5.22 – Relation OneToMany entre une page et les langues

Dans la figure 5.23, nous avons crée une page avec plusieurs langues : notamment en
français, anglais et italien.

Figure 5.23 – Un contenu multilingue

Après nous avons pu récupérer cette page dans des différents langues, comme présenté
dans les deux figures 5.24, et 5.25. Un contenu en anglais :

Figure 5.24 – Une page en anglais

La même page avec la langue italienne :

5.2. Réalisation 73

Figure 5.25 – Une page en italien

Récupération de composant de type Carrousel des produits

Après avoir configuré le carrousel des produits dans le CMS, tout en ajoutant les codes
produits correspondants. Le front fait appel au CMS, pour récupérer cette liste des codes
des produits. Par la suite avec ces codes récupérés, il fait appel aux trois APIs différents
du backend permettant l’affichage des informations des produits sur le carrousel, qui sont :

— L’API "Media" qui permet de retourner tous types de média : images, vidéos,
pictos, etc. [A1]
— L’API "Product", elle renvoie plusieurs attributs, par exemple le nom, la référence,
ainsi que la marque du produit qui vont être utilisé dans l’exposition du carrousel
sur le webshop. [A2]
— L’API "commerc-sku-detail", répond par les informations liées au prix, disponi-
bilité du produit, et les remises sur un produit. [A3]

L’image 5.26 montre comment le carrousel des produits est affiché sur le front.

Figure 5.26 – Un carrousel des produits

5.3. Évaluation des performances 74

5.3 Évaluation des performances

La vitesse du site Web est l’un des facteurs clés pour atteindre un classement élevé dans
les moteurs de recherche. C’est un facteur de classement important qui affecte directement
les performances d’un site Web. Améliorer les performances, l’indice de référencement
SEO du site Rubix a été l’un des enjeux la réarchitecture de la plateforme. Dans cette
section, nous présenterons une analyse des performances des pages du cms avant et après
l’implémentation de la nouvelle solution. Pour mener cette analyse, nous avons utilisé
l’Outil Google Lighthouse pour mesurer les performances et l’indice de référencement.

5.3.1 Lighthouse
Google Lighthouse est un outil open source développé par Google qui offre des fonc-
tionnalités d’audit de performances Web, d’accessibilité et d’applications Web progressives.
Il analyse les pages Web et génère des rapports détaillés contenant des recommandations
pratiques pour améliorer la qualité du site et l’expérience utilisateur. Lighthouse mesure
des métriques essentielles telles que le temps de chargement de la page, la conformité aux
normes d’accessibilité, tout en fournissant des informations sur les domaines à optimiser.

5.3.2 Mesure des performances

La figure 5.27, illustre un extrait du résultat de test de performance réalisés à l’aide
de l’outil Lighthouse pour la page "Page selection avantage gigaphone" crée par le CMS
Cockpit et la même page crée par le CMS Directus. L’outil Lighthouse fournit des infor-
mations et des valeurs précises, nous permettant d’évaluer l’efficacité de notre solution :

Figure 5.27 – Comparaison de résultat du test des performances

De plus on a pu mesuré, pour les deux pages, le temps nécessaire au navigateur pour
afficher le premier élément de contenu à l’écran. Indiqué par la métrique First Contentful
Paint (FCP) qui donne à quelle vitesse les utilisateurs voient quelque chose de significatif
se passe sur la page.
La figure 5.28, montre que le temps nécessaire pour afficher le premier élément a diminué
par rapport à la page définit par l’ancien CMS.
5.4. Conclusion 75

Figure 5.28 – Mesure de la valeur FCP

Les résultats des tests de performance révèlent des améliorations significatives tant au
niveau du référencement que des mesures de performance essentielles. La note de référence-
ment a augmenté de 82 à 87, ce qui témoigne d’une meilleure visibilité de la nouvelle page
crée avec le nouveau CMS, dans les résultats des moteurs de recherche. Les améliorations
observées au niveau de l’indicateur de performance, de temps d’affichage,etc, font preuve
de l’efficacité du CMS headless mis en place et de son impact positif sur la performance,
l’interactivité et l’expérience utilisateur des pages CMS.

5.4 Conclusion
L’étape d’achèvement est l’étape la plus importante, c’est l’achèvement de tous les
travaux effectués tout au long du projet. Ce chapitre est divisé en deux grandes parties.
La première a été consacrée pour montrer la configuration du contenu sur notre CMS,
et la deuxième a mis en valeur les différentes interfaces développées présentant certaines
des fonctionnalités de notre solution. Nous avons également clôturé ce dernier chapitre du
rapport par une évaluation des performances qui fait preuve de l’efficacité de notre solution.
Conclusion générale

Avec la montée en puissance des technologies web et la croissance continue du nombre

d’utilisateurs en ligne, les plateformes de commerce électronique connaissent une expan-
sion importante. Vu cette évolution constante de l’e-commerce, l’adoption d’une approche
headless offre de nombreux avantages en termes de flexibilité, de personnalisation et de
gestion de contenu. C’est dans ce cadre nous avons eu l’occasion de faire l’étude, la concep-
tion et la réalisation de l’intégration d’un CMS de type headless au sein de la plateforme
de commerce électronique Rubix qui est le premier distributeur en Europe de produits et
services de maintenance industrielle.

Durant notre stage, nous avons effectués des recherches et des études qui nous ont permis
de comprendre les concepts clés liés aux CMS headless et à l’e-commerce, ainsi que les défis
et les opportunités associés à leur intégration. Nous avons identifié les besoins fonctionnels
et non fonctionnels de notre projet, et effectué une analyse comparative approfondie de
deux CMS pertinents : Strapi et Directus.
Finalement on a réussi à faire une décision éclairée en choisissant Directus comme CMS
headless pour notre solution. Nous avons examiné les fonctionnalités offertes par Directus,
telles que la gestion des restrictions, le contenu multilingue et les performances des API,
qui répondent aux exigences de notre projet et aux besoins d’une entreprise multinationale
comme Rubix.

Le travail qui nous a été confié est en fait une opportunité qui nous a permis de tester
nos capacités de gérer un projet depuis l’étape initiale de «spécification» jusqu’à l’étape
finale de «mise en œuvre et de validation ». C’est ainsi que nous acquérons des compétences
en recherche, en programmation et en rédaction de rapports.

La solution implémentée au cours de ce projet présente tout de même certains points

d’améliorations, en raison de la durée limitée du projet, qui vont être le point de départ
des futures perspectives du projet. Parmi ces perspectives la migration des données de
l’ancien CMS vers le nouveau CMS. De même ajouter un système de notification dans le
CMS pour faciliter la collaboration de travail entre l’administrateur, et les développeurs
du site. Finalement pour mieux organiser le travail dans le système de gestion de contenu,
Directus propose la fonctionnalité de gestion des tickets qu’on peut la mettre en place.

76
Annexes

Documentation de l’API Media A1

La figure ci dessous illustre le retour de l’API media, utilisée pour afficher les images
du produit dans le carrousel.

Figure 5.29 – La réponse de l’API Media

77
Annexes 78

Documentation de l’API Sku Details A3

Dans l’image 5.30, nous présentons les informations retournées par l’API Products :

Figure 5.30 – Retour de l’API Products

Annexes 79

Documentation de l’API Commerce-sku-Details A3

La derniére API c’est l’API ayant comme réponse les prix, la disponibilité et les remises
liées à un produit. Comme indiqué dans la figure ci-dessous :

Figure 5.31 – Retour de l’API SkuDetails

Webographie

[1] Decade, “Notre entreprise.” [Link] [Consulté

le 16 Mars 2023].
[2] Rubix, “Qui sommes nous ?.” [Link]
[Consulté le 16 Mars 2023].
[3] DataScienTest, “Qu’est ce que la méthode agile ?.” [Link]
quest-ce-que-la-methode-agile, 2018. [Consulté le 26 mars 2023].
[4] “Définition e-commerce, son histoire, chiffres clés.” [Link]
definition-e-commerce/. [Consulté le 30 Mars 2023].
[5] F. Ziserman, “Hybris, solution pour bâtir un vrai système d’infor-
mation e-commerce.” [Link]
hybris-solution-pour-batir-un-vrai-systeme-dinformation-e-commerce/,
2019. [Consulté le 3 avril 2023].
[6] “Qu’est-ce qu’un cms ?.” [Link]
2019. [Consulté le 10 Avril 2023].
[7] L. Lacaze, “Cms traditionnel vs cms headless : quelles différences ?.” [Link]
[Link]/fr/cms-traditionnel-vs-cms-headless-quelles-differences/,
2020. [Consulté le 10 Avril 2023].
[8] S. A, “Understand how sap hybris cockpits framework enhances ecommerce expe-
riences.” [Link] 2019.
[Consulté le 17 avril 2023].
[9] “What’s docker.” [Link]
what-is-docker, 2019. [Consulté le 29 Avril 2023].
[10] Wikipédia, “Jakarta ee — wikipédia, l’encyclopédie libre.” [Link]
org/w/[Link]?title=Jakarta_EE&oldid=159136465, 2019. [Consulté le 9 mai
2023].
[11] Wikipédia, “Spring (framework) — wikipédia, l’encyclopédie libre.” [Link]
[Link]/w/[Link]?title=Spring_(framework)&oldid=159856465,
2019. [Consulté le 9 mai 2023].

80
Webographie 81

[12] Wikipédia, “React — wikipédia, l’encyclopédie libre.” [Link]

wiki/React. [Consulté le 9 juin 2023].
[13] Wikipédia, “Typescript — wikipédia, l’encyclopédie libre.” [Link]
org/wiki/TypeScript. [Consulté le 7 juin 2023].
[14] “Utiliser redux avec react js.” [Link]
utiliser-redux-avec-react-js/. [Consulté le 7 juin 2023].
[15] Wikipédia, “Eclipse — wikipédia, l’encyclopédie libre.” [Link]
wiki/Eclipse_(projet). [Consulté le 9 juin 2023].
[16] Wikipédia, “Intellij idea — wikipédia, l’encyclopédie libre.” [Link]
org/w/[Link]?title=IntelliJ_IDEA&oldid=158814565, 2019. [Consulté le 7
juin 2023].
[17] Wikipédia, “Postman — wikipédia, l’encyclopédie libre.” [Link]
org/wiki/Postman_(logiciel). [Consulté le 9 juin 2023].