Ollcavis 4

Référence : M2-GIL/2024.
01/EBx
Edition 01- Révision 01
Date : 24/09/23 - page 1/26
CAHIER DES CLAUSES

TECHNIQUES PARTICULIERES
© OllcAvis - Master II GIL 2023/2024

Référence : M2-GIL/2024.01/EBx
Date : 24/09/23 - page 2/26
1. Introduction 3
1.1. Objet Du Document 3
1.2. Objectifs Du Projet 3
1.3. Contexte 4
1.4. Cadre Applicatif 4
1.5. Contenu Du Document 5
1.6. Convention 5
2. Exigences Fonctionnelles Et Opérationnelles 6
2.1. Définitions préalables 6
2.2. Généralités et missions du système 6
2.3. Rôle des utilisateurs 7
2.4. Module d’invitation 8
2.5. Module de rédaction d’avis 9
2.6. Module de questionnaire 11
2.7. Module de réponse 12
2.8. Visualisation et signalement des avis/réponses 14
2.9. Module de modération 15
2.10. Module d’alerte 17
3. Exigences Techniques 18
3.1. Architecture 18
3.2. APIs 19
3.3. Technologies 19
4. Exigences De Management 20
5. Jalons Et Livrables 25

Date : 24/09/23 - page 3/26
1. Introduction
1.1. Objet Du Document
Le présent document décrit le contexte et le périmètre du projet proposé aux étudiants du
Master « Génie de l’Informatique Logicielle » pour l’année universitaire 2023-2024. Le projet
vise à simuler l’expérience de travail dans une entreprise qui vient de gagner une réponse à
appel d’offre. Les étudiants font partie de cette entreprise et doivent s’organiser pour
développer le système OllcAvis correspondant à l’appel d’offre gagné. Ce document
constitue le cahier des charges applicable au projet et sert de référence pour l’appel d’offres
remporté par la société fictive constituée des étudiants. La forme et la structure de ce CCTP
sont inspirées du code des marchés publics1. Il présente l'ensemble des exigences
fonctionnelles, de management et de qualités associées au projet. Il définit également la
liste des fournitures relatives au projet et le calendrier de livraison de ces fournitures.
1.2. Objectifs Du Projet

«OllcAvis» est un système de collecte et de gestion des avis clients intégré à une plateforme
de vente en ligne de produits alimentaires, et permettant de fournir des fonctionnalités
comme :
● Le dépôt, par un client, d’avis sur l’un des commerçants ou sur les produits qu’il a
commandé
● La consultation des avis clients
● La modération manuelle, par des modérateurs, des avis ne répondant pas aux
conditions d’utilisation du système d’avis.
● La modération automatique des avis au moyens d’algorithmes
Le système devra être construit de manière à permettre de s’interfacer avec la plateforme

d’e-commerce Ollca.
«OllcAvis» pourra être utilisé d’un PC, d’un smartphone ou d’une tablette.
Le système utilisé pour effectuer la démonstration sera désigné dans la suite du document
sous le nom de «OllcAvis» ou «système OllcAvis».
1.3. Contexte
Avec l'émergence des plateformes de vente en ligne comme Amazon, les habitudes de
consommation des utilisateurs ont évolué. En effet, ils ont intégré dans leur processus
d’achat, des étapes de sélection et de comparaison de produits de plus en plus longues et
1
www.marche-public.fr/Marches-publics/Definitions/Entrees/CCTP.htm

Date : 24/09/23 - page 4/26
complexes. Rares sont encore les utilisateurs qui ne s’appuient que sur les conseils donnés
par les vendeurs pour faire leur choix en comparaison de ceux qui vont chercher, au travers
des différents avis laissés par les consommateurs sur internet, à se faire leur propre idée
d’un produit avant de passer à l’acte d’achat. Pour se faire, les acheteurs vont dépenser un
temps important sur des applications dédiées d’avis client comme Google Review, ou
Trustpilot mais également sur les plateformes de vente lorsque celles-ci disposent d’avis
clients. Une plateforme de vente disposant d’un système d’avis client performant,
c’est-à-dire disposant de nombreux avis jugés utiles et fiables par les acheteurs, voit donc
naturellement augmenter ses chances de ventes. L’enjeu à disposer d’avis clients positifs
est devenu tellement important que des entreprises dédiées à la production de faux avis se
sont développées, amenant les autorités de contrôle du commerce (DGCCRF, Afnor) à
mettre en place des normes dédiées pour garantir l'authenticité des avis et éviter les
fraudes. La mise en place de ces normes complexifient encore les systèmes de gestion
d’avis et nécessitent la mise en place d’équipes de modération humaines coûteuses. Afin de
limiter ces coûts de modération, des algorithmes d’aide à la modération sont désormais
attendus. C’est dans cet objectif de proposer un système de gestion d’avis dédié et
performant que le développement du système «OllcAvis» est attendu.
1.4. Cadre Applicatif

Le système «OllcAvis» sera mis en place en interfaçant les APIs et technologies d’Ollca,
une plateforme e-commerce permettant aux commerçants et artisans des métiers de bouche
(boulangeries, boucheries, primeurs, fromagers, cavistes, épiceries...) de disposer d'une
boutique en ligne et de nouveaux services tels que la livraison et le retrait express en
boutique (click and collect). C'est une deuxième boutique pour le commerçant, lui assurant
une présence sur internet et offrant à ses clients la possibilité de commander en ligne
lorsqu'ils n'ont pas le temps ou ne peuvent pas se rendre en boutique. Le système est à
développer dans le cadre de l’évaluation des connaissances acquises en gestion de projet.
À ce titre, le respect des exigences de management sera fortement considéré lors de
l’évaluation des connaissances acquises en gestion de projet et de la notation.
1.5. Contenu Du Document

La première partie du document est consacrée à une description générale du système
«OllcAvis» et à la définition d’un certain nombre de notions relatives aux fonctionnalités ou
aux technologies à mettre en œuvre dans le projet.
La lecture de ces définitions constitue un prérequis indispensable pour la bonne

compréhension de la suite du document.
Chacune des fonctions «OllcAvis» fait l’objet d’une description dans laquelle sont exprimées
les exigences à satisfaire par le système «OllcAvis». Ce document définit ensuite les

Date : 24/09/23 - page 5/26
exigences techniques applicables à la conception et au développement du système

«OllcAvis». Enfin, le document définit les exigences de management qui devront être
respectées pour la conduite du projet.
1.6. Convention
Le présent CCTP a été rédigé en respectant les règles suivantes :
● Les exigences sont référencées selon le format suivant :

○ la lettre « E » pour « exigence » suivie d’un tiret bas « _ »,
○ trois lettres pour codifier la catégorie fonctionnelle de l'exigence, suivies d'un
tiret bas « _ »,
○ un numéro d'incrément de 10 en 10.
● Les codes utilisés au deuxième point sont les suivants:
○ ROL pour les exigences liées aux rôles des utilisateurs
○ INV pour les exigences liées aux invitations de dépôt d’avis
○ RED pour les exigences liées à la rédaction des avis
○ QST pour les exigences liées à la configuration des questionnaires
○ REP pour les exigences liées au module de réponse
○ VIS pour les exigences liées au module de visualisation et de signalement
○ MOD pour les exigences liées à la modération
○ ALR pour les exigences liées aux alertes
○ API pour les exigences de réalisations des API
○ ARC pour les exigences à l'architecture du système
○ TEC pour les exigences techniques de réalisation du système
○ MAN pour les exigences de managements du projet

Date : 24/09/23 - page 6/26
2. Exigences Fonctionnelles Et Opérationnelles

2.1. Définitions préalables
Dans la suite du document, les définitions ci-après seront utilisées pour la formulation des
exigences :
● Application Programming Interface (API) : Interface de programmation permettant

d’accéder à des fonctions, des procédures ou des classes d’objets mises à
disposition par un composant logiciel.
● Micro Service : Architecture logicielle visant à créer des services autonomes et
découplés et dont le périmètre métier est fortement spécialisé.
● CCTP : Cahier des clauses techniques particulières.
● Broker : Composant logiciel chargé de la distribution de messages à d’autres
composants logiciels
● Simple Page Application (SPA) : Application Web exécutée dans un navigateur web
et dont la navigation est pas gérée de façon autonome (non gérée par un serveur)
● SSO (Single Sign On) : Système de gestion centralisé des identités, de
l’authentification et des droits.
● Continuous Integration / Continuous Delivery (CI/CD): Système permettant
l'intégration et la livraison continue de composants logiciels
● RCD : Revue de conception détaillée
● IHM (Interface Homme Machine) : Composants logiciel permettant aux utilisateur
d’interagir avec le système
● SCRUM : Méthodologie de gestion agile de projets informatiques basée sur des
itérations logicielles fréquentes et des rôles
● LEAN : Méthodologie de gestion de projet informatiques centrée sur la plus value
métier pour le client
2.2. Généralités et missions du système

Le système «OllcAvis» doit permettre à de potentiels futurs acheteurs de consulter les avis à
propos de commerçants ou de leurs produits en vente sur la plateforme Ollca. Ces avis sont
collectés grâce au système OllcAvis auprès des clients Ollca. Comme les avis concernent
des commerçants (ou leurs produits), ces derniers pourront consulter les avis laissés par
leurs clients Ollca et y répondre. Le système doit également permettre à des administrateurs
de consulter les avis et les réponses déposés par les auteurs (client ou commerçant) afin
d’effectuer une éventuelle modération lorsque cela est nécessaire (contenu non intelligible,
propos diffamatoire, etc.). Cette modération permet aux modérateurs d’accepter ou de
refuser des avis. Le système inclut un module d’envoi d’invitations aux clients afin qu’ils

Date : 24/09/23 - page 7/26
donnent leur avis sur les produits qu’ils ont achetés récemment ainsi qu’un module d’aide et
d’assistance à la modération manuelle.
Le système «OllcAvis» devra s’interfacer avec la plateforme d’e-commerce Ollca ainsi

qu’avec d’éventuels outils externes.
Les fonctionnalités devront être développées au travers d’IHMs dédiées et accessibles au

travers d’une application web (SPA) reposant sur des APIs web.
2.3. Rôle des utilisateurs

Les exigences ci-après sont applicables à la définition des rôles de l'application et à
l’authentification sur le système.
E_ROL_10 Le système «OllcAvis» définit trois rôles principaux :
● un rôle d’auteur : utilisateur ayant effectué une commande Ollca lui

permettant de rédiger un avis
● un rôle de lecteur : utilisateur pouvant consulter les avis clients et signaler
aux modérateurs ceux qu’il juge suspects
● un rôle de modérateur : utilisateur capable de consulter les avis clients et de
les modérer (accepter/refuser)
● un rôle de commerçant : utilisateur capable de consulter les avis de ses
clients et d’y répondre, ainsi que de signaler ceux qu’il juge inapropriés
● un rôle administrateur : utilisateur ayant accès aux fonctions avancées du
système comme la configuration du système
E_ROL_20 L’accès aux fonctionnalités avancées du système (configuration des

algorithmes de modération automatique) n’est possible que pour les utilisateurs possédant
le rôle d’administrateur.
E_ROL_30 L’accès aux fonctionnalités de modération (accepter / refuser un avis)

n’est possible que pour les utilisateurs possédant le rôle de modérateur.
E_ROL_40 L’accès aux fonctionnalités de réponse aux avis n’est possible que
pour les utilisateurs possédant le rôle commerçant et pour les avis qui concernent sa
boutique ou les produits qu’il vend.
E_ROL_50 L’accès aux fonctionnalités de rédaction d’avis n’est possible que pour
les utilisateurs qui sont des clients de la plateforme Ollca.
E_ROL_60 L’accès aux fonctionnalités de signalement d’avis suspect est possible

pour les utilisateurs identifiés (c’est-à-dire authentifiés via la plateforme Ollca).

Date : 24/09/23 - page 8/26
2.4. Module d’invitation

Le module d’invitation permet d’envoyer par mail, aux clients de la plateforme Ollca, des
invitations à rédiger des avis sur une commande effectuée récemment. Dans ce cas, les
clients peuvent accéder au processus de rédaction d’avis (voir 2.5) en suivant le lien inclus
dans l’invitation.
Les exigences ci-après sont applicables au module d’invitation.
E_INV_10 Le système «OllcAvis» permet d’envoyer des invitations par mail aux
clients de la plateforme Ollca conformément aux règles suivantes :
● le client est sollicité pour donner un avis car lors de sa dernière commande, il
a commandé dans une boutique pour laquelle il n’a encore jamais donné son
avis
● le client est sollicité pour donner un avis car lors de sa dernière commande, il
a commandé un produit pour lequel il n’a encore jamais donné son avis
● l’invitation est envoyée dans un délai de 48h après la date de retrait / livraison
de la commande associée
E_INV_20 Le système «OllcAvis» permet d’envoyer des invitations par mail aux
clients de la plateforme Ollca conformément aux règles suivantes :
● le client a déjà été sollicité conformément à E_INV_10 mais n’a pas encore
rédigé d’avis
● L’invitation est envoyée dans un délai de 168h (7 jours) après la date de
retrait / livraison de la commande associée
E_INV_30 Lorsqu’une invitation est envoyée à un client, elle contient un résumé

de la commande à évaluer (boutique(s) concernée(s), date de la commande, produit(s), etc.)
ainsi qu’un lien permettant d’accéder au module de rédaction d’avis.
E_INV_40 Le système «OllcAvis» écoute le topic Kafka “order” afin de récupérer

en temps réel les commandes créées sur la plateforme Ollca pour envoyer les invitations

Date : 24/09/23 - page 9/26
2.5. Module de rédaction d’avis

Le système «OllcAvis» permet à un utilisateur de rédiger des avis, à propos d’une
commande qu’il a effectuée, à partir d’un lien envoyé par le module d’invitation (voir 2.4).
L’utilisateur peut, au travers d’un processus unique, rédiger autant d’avis que de boutiques
et de produits associés à sa commande. Chaque avis (produit ou boutique) se décompose
en deux parties: la première, obligatoire, permet au rédacteur de laisser une note (entre 1 et
5) et un commentaire (texte libre). Cette première partie constitue la partie visible
publiquement de l’avis (voir 2.8). La seconde partie, optionnelle, permet d’enrichir la
première partie au moyen d’éléments de détails sélectionnables. Les détails recueillis ne
sont visibles que par les administrateurs, les modérateurs et les commerçants à des fins
d’analyse et d’amélioration de l'expérience utilisateur. Le fonctionnement des éléments de
détail est détaillé en 2.6.
E_RED_10 Le système «OllcAvis» permet à un client de la plateforme Ollca

d'accéder au module de rédaction d’avis au travers d’un lien qu’il aura reçu en invitation (voir
2.4). Lors de l’accès au module de rédaction, le système récupère l’identité du rédacteur
auprès du SSO Ollca et vérifie qu’il est bien l’acheteur associé à la commande à évaluer.
E_RED_20 Le système «OllcAvis» permet à un rédacteur de masquer son identité

complète (en affichant uniquement ses initiales) ou d’utiliser un pseudonyme lors de la
rédaction d’un avis.
E_RED_30 Le système «OllcAvis» permet à un rédacteur d’accéder à un

processus unique (formulaire/page unique) lui permettant de donner son avis sur les
boutiques et les produits de la commande associée à l’invitation. Pour chaque avis, le
rédacteur doit définir une note (entre 1 et 5) et un commentaire (texte libre) pour que son
avis soit pris en compte. Lorsqu’une note est saisie, les éléments de détails optionnels
configurés par l’administrateur dans le module de questionnaire (voir 2.6) sont présentés et
sont sélectionnables par le rédacteur.
E_RED_40 Lors de la création d’un avis, le système «OllcAvis» présente de façon

ergonomique:
● la date de la commande
● la description de la boutique évaluée (si avis boutique)
● la description du produit évalué (si avis produit)
E_RED_50 Lors de la création d’un avis, le système «OllcAvis» enregistre les

informations suivantes :
● l’id de l’avis
● l’id du rédacteur
● le pseudonyme renseigné par le rédacteur ou, par défaut, ses initiales

Date : 24/09/23 - page 10/26
● la date de création de l’avis

● la date de dernière modification de l’avis
● l’id du produit ou de la boutique associé à l’avis (sujet)
● l’id de la commande
● la date de la commande
● le statut “avis”
● la note entre 1 et 5
● le commentaire (texte libre)
● les éventuels éléments de détails sélectionnés par le rédacteur
● un historique horodaté des événement associés à l’avis (initialisé avec
l'événement de création)
E_RED_60 Le système «OllcAvis» permet à un rédacteur de lister ses avis et d’en

consulter les détails (statut, le pseudonyme visible publiquement / initiales, date de création
de l’avis, date de dernière modification de l’avis, produit ou de la boutique associé, lien vers
la commande, note, commentaire, éléments de détails sélectionnés)
E_RED_70 Le système «OllcAvis» permet à un rédacteur, depuis la liste de ses

avis ou depuis ses détails, de modifier un avis dans un délai d’un mois après sa date de
création. Lors de la modification d’un avis, le système met à jour les champs de l’avis
modifiés par l’auteur, la date de dernière modification et ajoute un événement de
modification à l’historique des événements. Les éléments de détails sélectionnés
précédemment peuvent être désélectionnés (même s’ils ont été supprimés par
l’administrateur dans le module de questionnaire), mais seuls les éléments de détails
actuellement configurés par l’administrateur sont sélectionnables. Si le contenu est modifié,
il doit être de nouveau modéré (voir E_MOD_90)
E_RED_80 Le système «OllcAvis» permet à un rédacteur, depuis la liste de ses

avis, de retirer un avis dans un délai d’un mois après sa date de création. Lors de la
désactivation d’un avis par son rédacteur, le système passe son statut à “désactivé par par
le rédacteur” et ajoute l’événement à l’historique des événements. Un avis désactivé n’est
plus visible publiquement mais reste visible par son rédacteur.
E_RED_90 Le système «OllcAvis» ne permet pas à un rédacteur de laisser un

nouvel avis sur les boutiques ou les produits qu’il a déjà précédemment évalués. Si le
rédacteur accède au processus de rédaction via un lien d’invitation, seules les boutiques ou
les produits encore non évalués sont évaluables. Le système indique de façon ergonomique
les boutiques ou produits déjà évalués et permet au rédacteur d’éditer ou de désactiver les
avis existants associés.

Date : 24/09/23 - page 11/26
2.6. Module de questionnaire

Le module de questionnaire permet à un administrateur de configurer les éléments de
détails qui sont sélectionnables par un rédacteur d’avis en fonction de la note attribuée et du
type d’avis (boutique ou produit). Ces éléments de détails aident les rédacteurs, leur
permettant d’évaluer plus rapidement des aspects précis et pertinents, augmentant la qualité
des retours clients, tout en facilitant leur l’analyse. Ainsi, si lors de la rédaction d’un avis, le
rédacteur attribue une mauvaise note, des éléments de détails portant sur les causes
possibles de son insatisfaction lui sont proposés (qualité du produit, service en boutique,
etc.). Dans le cas des avis produits, la catégorie du produit conditionne également ces
éléments de détails. Par exemple, si la catégorie du produit évalué est “Fruit”, le système
propose des éléments de détails adaptés comme “Fruit pas assez mûrs”.
E_QST_10 Le système «OllcAvis» permet à un utilisateur avec un rôle

d’administrateur de créer des éléments de détails et de configurer les conditions de leur
affichage lors de la rédaction d’un avis. Un élément de détail est composé des champs
suivant:
● le label présenté au rédacteur

● l’interval de note (entre 1 et 5) auquel s’applique l’élément de détail
● type d’avis auquel s’applique l’élément de détail (avis produit ou avis
commerçant)
● catégorie métier du produit (légume, volaille, etc.) auquel s’applique l’élément
de détail (si l’élément est applicable à un avis est de type produit)

d’administrateur de lister les éléments de détails et de voir pour chacun :
● le label
● l’interval de note
● le type d’avis
● la catégorie produit (si applicable)
● le nombre de fois où cet élément de détail est sélectionné dans des avis

d’administrateur de filtrer et trier les éléments de détails selon les champs des éléments de
détail (voir E_QST_20).

d’administrateur de supprimer des éléments de détails.

Date : 24/09/23 - page 12/26
2.7. Module de réponse

Les commerçants peuvent répondre aux avis rédigés par les clients les concernant (avis sur
sa boutique ou sur les produits de sa boutique). Cela permet aux commerçants de disposer
d’un droit de réponse aux éventuels avis négatifs des clients mais également de remercier
les clients ayant déposé des avis positifs.
E_REP_10 Le système «OllcAvis» permet à un utilisateur avec un rôle de

commerçant de lister tous les avis concernant sa boutique et ses produits et d’afficher pour
chacun les champs :
● note
● date de création
● auteur
● la commande liée
● l’état de la modération automatiquement (status, date de modération, résultat
de la modération, raison(s) si non conforme)
● l’état de la modération manuel (status, date de modération, modérateur,
résultat de la modération, raison(s) si non conforme)
● le lien vers sa réponse si elle existe
● le produit ou la boutique sujet de l’avis

commerçant de filtrer et trier tous les avis concernant sa boutique en fonction des champs:
● note
● auteur
● statut de la modération effectuée (manuelle ou automatique)

commerçant, depuis la liste de ses avis, d’en sélectionner un pour en afficher les détails
(éléments de détails, commentaire, note etc.) et pour rédiger une réponse au moyen d’un
champ texte libre. Lors de création d’une réponse, le système enregistre les champs
suivants:
● l’id de la réponse
● l’id de l’avis associé à la réponse
● le rédacteur de la réponse (commerçant)
● le contenu de la réponse (texte)

Date : 24/09/23 - page 13/26

Lors de la création d’une réponse, le système initialise les états de modérations

(automatique et manuel) pour permettre une modération (voir E_MOD_90).

commerçant, de modifier une réponse dans un délai d’un mois après sa date de création.
Lors de la modification d’une réponse, le système réinitialise les états de modérations
(automatique et manuel) pour permettre une nouvelle modération (voir E_MOD_90).

commerçant, depuis la liste de ses avis, d’en signaler un comme ayant un contenu non
conforme, de la même façon que spécifié par E_VIS_40.

Date : 24/09/23 - page 14/26
2.8. Visualisation et signalement des avis/réponses

Les avis rédigés par les rédacteurs et les réponses des commerçants doivent être visibles
des autres utilisateurs de la plateforme Ollca au niveau des boutiques ou produits afin d’en
tirer profit. De plus, tout utilisateur authentifié accédant à un avis ou une réponse peut
signaler son contenu comme non-conforme aux modérateurs. Par conséquent, les
fonctionnalités de visualisation et de signalement doivent s’intégrer directement à
l’écosystème Ollca (site par exemple), ce qui implique la mise en place de modules de
présentation web indépendants (Web Module) ainsi que l’accès aux données liées aux avis
au moyen d’une API. Cependant, la démonstration des modules web / APIs au sein du
système «OllcAvis» est attendue.
E_VIS_10 Le système «OllcAvis» permet à une application distante de récupérer

les données liées aux avis clients / réponses commerçants au moyen d’une API afin d’en
permettre leur visualisation. Cette API accepte en paramètre l’id de boutique ou de produit
dont on souhaite récupérer les données.
E_VIS_20 Le système «OllcAvis» propose des modules web, intégrables dans

une application web externe, permettant la visualisation de la note moyenne, des avis clients
et des réponses commerçants pour une boutique ou pour un produit. Les modules web
acceptent en paramètre l’id de boutique ou de produit.
E_VIS_30 Le système «OllcAvis» permet à une application distante de signaler

le contenu d’un avis ou d’une réponse comme non-conforme au moyen d’une API.
L’utilisateur doit justifier son signalement au moyen d’un champ texte de justification. Les
paramètres attendus par l’API sont:
● l’id de l’avis ou de la réponse,

● l’id de l’utilisateur à l’origine du signalement (récupéré du token OAuth)
● le champ texte de justification
Lors d’un signalement, l’avis ou la réponse et son historique d'événement sont mis à jour et
sa visibilité est changée comme spécifié par E_MOD_80.
E_VIS_40 Le système «OllcAvis» propose des modules web, intégrables dans

une application web externe, permettant de signaler que le contenu d’un avis ou d’une
réponse est non conforme. Les modules acceptent en paramètre l’id de l’avis ou de la
réponse. Lors d’un signalement, l’avis ou la réponse et son historique d'événement sont mis
à jour et sa visibilité est changée comme spécifié par E_MOD_80

Date : 24/09/23 - page 15/26
2.9. Module de modération

La modération consiste à vérifier les contenus pour identifier ceux qui ne respectent pas les
conditions d’acceptation (texte illisible, incohérent ou dans la mauvaise langue, propos
diffamatoires ou insultes, sans rapport avec le produit ou le commerçant évalué,
non-impartial, etc.). La modération peut être effectuée manuellement par des modérateurs
humains ou de façon automatique au moyen d’algorithmes. La modération s’applique au
contenu des avis et des réponses (champ commentaire et réponse). Les avis et les
réponses dont le contenu est non-conforme ne sont pas ou plus visibles publiquement. Les
modérateurs accèdent à l’ensemble des avis et des réponses et peuvent à tout moment
changer leur statut de modération manuel, ce qui modifie leur visibilité publique. Les
contenus signalés comme non conforme par les utilisateurs authentifiés (y compris les
commerçants) ne sont plus visibles publiquementet doivent être modérés manuellement (et
validés) pour le redevenir.
E_MOD_10 Le système «OllcAvis» permet à un utilisateur avec un rôle de

modérateur de lister tous les contenus et d’afficher pour chacun :
● l’auteur
● un extrait du contenu à modérer (texte)
● le type d’élément associé au contenu (avis ou réponse)
● la note et le type de l’avis associé (si contenu d’un avis)
● le lien vers l’avis associé à la réponse (si contenu d’une réponse)
● la date de création du contenu
● si le contenu a été signalé manuellement comme non conforme et sa
justification

modérateur de filtrer et trier les contenus (avis et réponses) selon les champs :
● note de l’avis (si le contenu est associé à un avis)

● type d’avis (si le contenu est associé à un avis)
● statut de la modération automatique
● statut de la modération manuel
● contenu signalé
● date de modération (automatique ou manuelle)
● auteur
● modérateur

Date : 24/09/23 - page 16/26

modérateur de déclarer comme non-conforme (refuser) un contenu associé à un avis ou à
une réponse. Dans ce cas, le modérateur doit justifier la raison du refus parmi une liste de
raisons prédéfinies, ainsi qu’un champ texte libre. Le système met à jour l’avis ou la réponse
(le statut de modération, date de modération, raison, modérateur) et ajoute l'événement à
l’historique d'événement.

modérateur de valider le contenu d’un avis ou d’une réponse. Le système met à jour l’avis
ou la réponse (le statut de modération, date de modération, raison, modérateur) et ajoute
l'événement à l’historique d'événement.
E_MOD_50 Le système «OllcAvis» permet de modérer automatiquement au

moyen d’un algorithme le contenu des avis ou des réponses. Suite à l’analyse automatique
d’un contenu, le système met à jour l’historique des événements et les champs associés à la
modération automatique (status, résultat, etc.).
E_MOD_60 Le système «OllcAvis» rend non visible publiquement un avis ou une

réponse dont le contenu a été refusé (jugé non-conforme) par une modération manuelle ou
automatique.
E_MOD_70 Le système «OllcAvis» rend non visible publiquement un avis ou une

réponse dont le contenu a été signalé comme non-conforme tant qu’il n’a pas été modéré
manuellement et validé (accepté). Si le contenu est déclaré comme non-conforme par le
modérateur, l’avis ou la réponse reste non visible publiquement.
E_MOD_80 Le système «OllcAvis» re-initialise le statut de modération

(automatique / manuel) lorsqu’un contenu est modifié par son auteur afin que le contenu
modifié soit de nouveau modéré.
E_MOD_90 Le système «OllcAvis» permet, lors de modèration d’un contenu, de

voir les métadonnées suivantes de son rédacteur :
● fréquence de rédaction de contenu

● historique des rédactions

Date : 24/09/23 - page 17/26
2.10. Module d’alerte

Le système d’alerte permet de signaler aux utilisateurs du système «OllcAvis» des
événements d’intérêt le concernant.
E_ALR_10 Le système «OllcAvis» envoie une alerte aux utilisateurs avec un rôle
de modérateur lorsque le délai de modération d’un contenu est expiré. Le mail contient le
détail de l’avis ou de la réponse associé au contenu ainsi qu’un lien permettant d’accéder au
module de modération pour ce contenu.
de commerçant lorsqu’un avis concernant sa boutique ou ses produits a été rédigé. Le mail
contient le détail de l’avis associé au contenu ainsi qu’un lien permettant d’accéder à sa
visualisation.
de modérateur lorsqu’un contenu est signalé comme non conforme par un utilisateur. Le
mail contient le détail de l’avis ou de la réponse associé au contenu signalé ainsi qu’un lien
permettant d’accéder au module de modération pour ce contenu.
E_ALR_40 Le système «OllcAvis» notifie un rédacteur lorsque le contenu de l’un

de ses avis est refusé lors de sa modération, en précisant la raison du refus. Un lien permet
à rédacteur d’accéder à la modification de son avis.
E_ALR_50 Le système «OllcAvis» notifie un commerçant lorsque le contenu de

l’une de ses réponses est refusé lors de sa modération, en précisant la raison du refus. Un
lien permet au commerçant d’accéder à la modification de sa réponse.

Date : 24/09/23 - page 18/26
3. Exigences Techniques
3.1. Architecture
Le système «OllcAvis» est basé sur une architecture orientée micro-service où chaque
service est indépendant et autonome. Les micro services sont réactifs, c'est-à-dire qu’ils
réagissent à des messages issus de flux de données ou à des appels à leurs APIs.
E_ARC_10 Le système «OllcAvis» est composé de micro-services indépendants

et autonomes. Si l’un des micro services est indisponible, l’ensemble du système continue à
fonctionner et seules les fonctionnalités liées à ce service sont indisponibles.
E_ARC_20 Chaque micro-service dispose de son propre système de gestion de

données indépendant. Par exemple, une base de données ne doit pas être utilisée par
plusieurs micro-services.
E_ARC_30 Chaque micro-service du système «OllcAvis» gère un nombre limité

d’objets métiers (liés au périmètre fonctionnel du service) dont il assure la diffusion sur des
flux de données dédiés (topic Kafka). Autrement dit, pour un type d’objet métier donné, un et
un seul service pourra diffuser les objets métier créés / modifiés ou supprimés sur le flux de
données correspondant.
E_ARC_40 Chaque micro-service du système «OllcAvis» effectue ses traitements

à partir des données reçues depuis ses APIs ou à partir des objets métiers issus des flux de
données d’objets métier (topics Kafka).
E_ARC_50 Un micro-service du système «OllcAvis» ne peut communiquer

directement avec les autres micro-services via ses APIs. Autrement dit, aucun micro-service
n’a connaissance des autres micro-services.
E_ARC_60 Les objets métiers échangés sur les flux de données respectent un
modèle d’échange commun. Ce modèle permet à chaque service de traiter si besoin les
objets métiers disponibles des flux de données gérés par les autres services.
E_ARC_70 La sécurisation des APIs, la gestion des utilisateurs et leur

authentification se fait conformément au protocole OpenIdConnect en exploitant un SSO.

Date : 24/09/23 - page 19/26
3.2. APIs
Le système «OllcAvis» doit pouvoir s’intégrer facilement dans une plateforme existante.
Pour se faire, les différentes fonctionnalités mises en œuvre doivent être accessibles au
travers d’APIs web.
E_API_10 Le système «OllcAvis» met à disposition une API Web REST/JSON

permettant d’accéder aux fonctionnalités des modules détaillées en 2.4, 2.5, 2.6, 2.7, 2.8,
2.9, 2.10, 2.11.
E_API_20 Le système «OllcAvis» met à disposition des APIs sans état

(RESTFull) afin de permettre leur redondance et leur mise à l'échelle.
3.3. Technologies
E_TEC_10 Le système «OllcAvis» doit traiter des flux de données gérées au
travers d’un cluster Kafka.
E_TEC_20 Les micro services développés doivent s’appuyer sur le framework

Spring Boot.
E_TEC_30 Les micro services développés doivent s’appuyer au maximum sur

des technologies existantes (APIs externes, librairies/framework, algorithmes).
E_TEC_40 La sécurisation des micro services développés, la gestion du login et

des droits doivent se faire en exploitant le protocole OpenId Connect via l’outil Keycloak.
E_TEC_50 Les fonctionnalités graphiques développées doivent être accessibles

au travers de composants Web indépendants et démontrable au sein d’une application
basée sur le framework Angular.
E_TEC_60 Toute opération sur l'IHM du système «OllcAvis» doit se faire en

moins de 5 secondes (affichage d'une page, etc..). Dans le cas contraire, le client devra être
averti dès la phase de développement pour valider le comportement du système. Le cas
échéant, l'utilisateur est alerté lors de l'utilisation d'une de ces fonctions (message, barre de
progression, loader, etc.)

Date : 24/09/23 - page 20/26
4. Exigences De Management
L’approche retenue pour le développement repose sur un processus de livraison continu
(CD) au travers d’une méthodologie de type SCRUM. Cette méthodologie devra permettre la
mise en place de sprints conduisant à une amélioration progressive du document
d’architecture logiciel lors de la phase de LEAN, et de la couverture fonctionnelle lors de la
phase développement. Afin de suivre finement l’avancement du projet, des mêlées
quotidiennes seront organisées dès la phase de LEAN, au cours desquelles le client pourra
participer.
Lors de chaque sprint, des équipes de développement seront constituées et réaliseront les
tâches conformément à une liste priorisée (backlog). Le backlog sera constitué à partir de
scénarios d’utilisation du système (user story).
À la fin de chaque sprint, une revue de sprint sera organisée où sera faite une
démonstration du système permettant de valider les fonctionnalités du système mises en
place.
E_MAN_10 Le projet «OllcAvis» doit être réalisé en suivant un mode de

développement agile (Lean Startup & SCRUM) s’appuyant sur les événements suivants :
● MVP (Minimal Viable Product)

● Création de user stories
● Création ou mise à jour du backlog
● Planification des sprints
● Création et mise à jour de Kanban
● Création et mise à jour d’un rétroplanning
● Tenue de mélés quotidiennes
● Tenue de revues de sprint
● Tenue de rétrospectives de sprint
E_MAN_20 Un responsable produit (product owner) doit être identifié et doit :
● Avoir la vision produit du système, c’est à dire connaître les besoins du client
et des utilisateurs
● Diffuser la vision produit à l’ensemble des équipes
● Prioriser les fonctionnalités à développer avec l’accord du client
● Aider les scrums masters à prioriser les éléments du backlog (tâches)
● Assurer que les fonctionnalités à développer soient correctement diffusées et
comprises par l’ensemble des équipes
● Planifier avec les scrums masters le contenu des sprints

Date : 24/09/23 - page 21/26
E_MAN_30 Un responsable technique doit être identifié et doit :
● Avoir la vision technique du système, c’est-à-dire connaître l’architecture du

logiciel et comment les fonctionnalités doivent être implémentées
● Diffuser la vision technique à l’ensemble des équipes
● Être proactif en cas de problème technique durant la phase de
développement
● Aider à la priorisation des éléments du backlog (tâches)
● S’assurer que les fonctionnalités développer respectent le Document
d’Architecture Logiciel
E_MAN_40 Des responsables de mêlée (scrum master) pour les différentes

équipes de développement doivent être identifiés et doivent :
● Organiser leur backlog en fonction des fonctionnalités prioritaires définies par

le product owner
● Aider à la compréhension du processus scrum à son équipe
● S’assurer du respect du processus scrum dans son équipe
● Assurer que les éléments du backlog soient correctement diffusées et
comprises par son équipe
● Gérer son équipe de développement
● Communiquer avec les autres scrum master des différentes équipes
E_MAN_50 Un référent de la méthode scrum doit être identifié et doit :
● Définir et s’assurer de la compréhension d’un processus scrum commun aux

équipes
● Diffuser les outils communs et les méthodes communes aux équipes
permettant d’appliquer la méthodologie scrum
● Faciliter la communication entre les équipes
E_MAN_60 Le système est développé au travers de sprints d’une durée maximale

de 10 jours ouvrés.
E_MAN_70 Avant chaque sprint, des user stories sont identifiées pour ce sprint
par le Product Owner et validé par le Client. L’équipe de développement doit avoir validé la
faisabilité de ses user stories dans le temps imparti du sprint.
E_MAN_80 Avant chaque sprint, un backlog de tâches priorisées et finement

découpées s’appuyant sur les user stories doit être identifié.
E_MAN_90 Pour chaque sprint, des équipes de développement sont identifiées et

associées à une ou plusieurs tâches du backlog.

Date : 24/09/23 - page 22/26
E_MAN_100 Pour chaque sprint, des scrum master propres à chacunes des
équipes sont identifiés.
E_MAN_110 Des mêlés quotidiennes sont organisées et accompagnées d'un

rapide compte rendu.
E_MAN_120 À la fin de chaque sprint, des revues de sprint sont organisées et un

compte rendu est produit.
E_MAN_130 À la fin de chaque sprint, des rétrospectives de sprint sont organisées

et un compte rendu est produit.
E_MAN_140 Une réunion de cadrage est réalisée afin de créer une version initiale
du backlog. Cette réunion traite les thématiques suivantes :
● Vision et enjeux du premier sprint

● Roadmap et carte fonctionnelle
● Architecture du système
● Organisation des équipes et des moyens
● Rôles et responsabilités
● Risques
E_MAN_150 Le product owner du projet «OllcAvis» fourni chaque semaine un

rapport d'avancement dans lequel figure les événements marquants, des éléments
qualitatifs sur le déroulement du projet et quelques indicateurs quantitatifs tels que le
nombre de User Story implémentées, le nombre d'exigences couvertes, le nombre de story
point consommé, le nombre de faits techniques relevés et corrigés, etc.
E_MAN_160 La définition de l’interface homme-machine du système «OllcAvis» fait

l'objet d'un maquettage. Celui-ci a pour objectif de présenter une image du comportement du
système permettant de valider et d’affiner, dès que possible, l'expression de besoin, y
compris fonctionnel (en complément des éléments du présent CCTP) en suscitant des
commentaires de la part des futurs utilisateurs du système.
E_MAN_170 Le maquettage des IHMs se déroule sous la forme d’une procédure

itérative donnant lieu à au moins trois présentations pendant la phase de LEAN.
E_MAN_180 Le product owner fournit au client un document d’architecture

synthétique et réfléchi précisant les choix structurants d’architecture effectués. Ce document
est rédigé par les différentes équipes collaborativement et contiendra :
● L’architecture logicielle en couche haut niveau de l’application,

● L’architecture matérielle (serveurs, firewall, etc.) retenue pour le déploiement de
l’application

Date : 24/09/23 - page 23/26
● L’identification des composants logiciels existants et à développer (micro-services,

application web) et les interactions / liens entre-eux
● Une partie dédiée à la sécurité qui expliquera les moyens et techniques misent en
place pour garantir la sécurité des données et du système
Il n’est pas demandé de présenter la conception interne détaillée des composants dans ce
document (diagramme de classe ou d’activité interne à l’implémentation du composant) mais
les détails des méthodes des apis et des payload formalisés en JSON des I/O et des objets
métiers echangés seront eux détaillés précisement pour chaque service.
E_MAN_190 Chaque personne participant au projet doit rédiger un document

descriptif (de 8 pages minimum) de ses travaux au sein du projet listant succintement ses
principales contributions managériales et/ou techniques, les rédactions effectuées, et en
insistant fortement sur les principales difficultés managériales / méthodologiques /
techniques rencontrées, et les modes de résolution associés. L’accent sera mis sur les
réponses et solutions apportées pour dépasser les difficultés rencontrées lors de
l’application de la méthodologie scrum plutôt que sur les contributions techniques.
E_MAN_200 Pour chaque présentation du système en fin de sprint, le product

owner doit fournir :
● Un plan de validation détaillée, rédigé par chaque équipe, qui décrira la stratégie de
test fonctionnelle mise en œuvre, les conditions de réalisation des tests, les
procédures de tests et les jeux de données utilisés, les résultats constatés ainsi
qu’une matrice de couverture établissant la correspondance entre les users stories et
les procédures de test visant à la vérifier, (il n’est pas demandé ici de décrire les
tests unitaires des composants mais bien les tests « manuels » fonctionnels
permettant de bien valider le système intégré),
● Une fiche de version du système livré décrivant les exigences couvertes par la
version de l’application, les évolutions prises en charge par la version, les limites
éventuelles et les anomalies résiduelles
● Un bilan de validation de la version du système mettant en avant les résultats de
l’exécution du plan de test ainsi que le taux de couverture et les résultats des tests
unitaires.
E_MAN_210 Pour chaque présentation du système en fin de sprint, le product

owner fournit un audit de sécurité.
E_MAN_220 Des outils de gestion du code source, de configuration et de version

doivent être mis en place. Ils intégrent :
● Une gestion du code source Git

● Une gestion de fiches de faits techniques (rapports d’anomalies, demandes
d’évolutions).

Date : 24/09/23 - page 24/26
● Une gestion des versions des différents composants du logiciel.
On étudiera en particulier la possibilité d’utiliser un seul et même outil. L’accès à ce ou ces

outils est accessible par le client.
E_MAN_230 Un document détaillant l’ensemble des règles de codage ainsi que les
bonnes pratiques de réalisation et d’ingénierie est fourni. Sont décrit a minima dans ce
document :
● La structure arborescente du code source

● Les noms de package
● Le naming des classes, interfaces, variables, tables, méthodes
● Les designs patterns à utiliser et dans quels cas
● Les règles et bonnes pratiques liées à la sécurité des données et du système
● La nature des tests à mettre en place en fonction du type de composant
● Les règles et bonnes pratiques liées à l’intégration des composants entre eux
● Un template de documentation des composants (javadoc + api)
● Un template des messages de commit
● Un template des messages de ticket (bug)
● Un template pour la documentation rapide (readme)
E_MAN_240 Une revue de conception détaillée (RCD) du projet a lieu à l'issue de

la phase de conception avant le démarrage effectif de la phase de développement. Lors de
cette revue, le product owner exprime le besoin du client en besoins fonctionnels et
techniques et chaque équipe identifiée présente les éléments du backlog lui étant attribués
ainsi que les approches techniques retenues pour leur implémentation. Chaque personne
impliquée dans le projet doit effectuer une présentation courte de ses travaux lors de cette
réunion.
E_MAN_250 Durant la phase de Lean, des prototypes permettant de valider la

maîtrise des outils et technologie par les équipes de développement seront développés et
présentés au client. La présentation du prototype au client se fera préférentiellement par les
personnes impliquées dans le développement du prototype.
E_MAN_260 Une réunion de clôture du projet se déroule à l'issue de la phase de

réalisation. Lors de cette revue, chaque équipe impliquée dans le projet présente les
principales réalisations effectuées relativement aux parties du backlog qui lui ont été
attribuées. Chaque personne impliquée dans le projet doit effectuer une présentation courte
de ses travaux lors de cette réunion. A l'issue de cette présentation, le product owner
effectue une démonstration de 20 mn du système «OllcAvis» suivant un scénario de
démonstration validé avec le client. Le "scénario" de cette démonstration est proposé au
client au plus tard deux semaines avant la revue finale pour approbation.

Date : 24/09/23 - page 25/26
E_MAN_270 En fin de projet, le product owner doit fournir un kit de communication

contenant un diaporama de présentation et une démonstration filmée du système s'appuyant
sur le scénario final de démonstration.
5. Jalons Et Livrables
Le tableau ci-dessous donne la liste des livrables (a minima) et leur date de livraison
au plus tard au titre du présent projet. Ces dates sont données par rapport à la date
de notification du projet (T0) ; et la date du début du développement (T1).
Le projet se déroulera en deux phases principales. La première phase de

préparation et de conception, appelée Lean Startup, se déroulera du 23/09/23 (T0)
au 17/01/24. La seconde phase, Scrum, orientée développement se déroulera du
25/01/24 (T1) au 25/03/23.
Lors de la phase de Scrum, le projet sera réalisé au travers de différents Sprints,

d’une durée maximale de 10 jours (ouvrés). À la fin de chaque Sprint:
● une démonstration sera effectuée,

● de nouvelles User stories seront créées,
● le backlog sera mis à jour et validé par le client,
● une proposition de rôles et d’équipes de développement du sprint suivant.

Date : 24/09/23 - page 26/26
Identifiant Description Date de

livraison
Lean Startup
ORG-PREP Rôles et équipes de préparation T0 + 1 sem.
SRC-PRAT Guide des bonnes pratiques et règles de codage T0 + 4 sem.
PROTO-x Prototypes techniques des différentes équipes T0 + 8 sem.
SRC-FORG Usine logiciel et gitflow T0 + 10 sem.
ORG-CONC Rôles et équipes de conception T0 + 11 sem.
DAL Document d’architecture générale + maquettes initiales T0 + 8 sem.

(une version maj toute les 2 semaines)
STOR-INIT User Stories initial T0 + 13 sem.
BACK-INIT Backlog initial T0 + 13 sem.
DAL Document d’architecture générale final + maquettes T0 + 16 sem.
Scrum
ORG-INIT Rôles et équipes de développement Sprint 1 T0 + 16 sem.
RET-x Rapport Sprint x T1 + y jours.
STOR-x User Stories Sprint x + 1 T1 + y jours.
BACK-x Backlog Sprint x + 1 T1 + y jours.
ORG-x Rôles et équipes de développement Sprint x + 1 T1 + y jours.
SRC-SYS Code source du système T1 + 9 sem.
COM Kit de communication T1 + 9 sem.
RAP-IND Rapports individuels de réalisation T1 + 9 sem.

Ollcavis 4

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ollcavis 4

Transféré par

Droits d'auteur :

Formats disponibles

Référence : M2-GIL/2024.

Edition 01- Révision 01

Date : 24/09/23 - page 1/26

CAHIER DES CLAUSES

© OllcAvis - Master II GIL 2023/2024

Edition 01- Révision 01

Date : 24/09/23 - page 2/26

© OllcAvis - Master II GIL 2023/2024

Edition 01- Révision 01

Date : 24/09/23 - page 3/26

1.2. Objectifs Du Projet

Le système devra être construit de manière à permettre de s’interfacer avec la plateforme

© OllcAvis - Master II GIL 2023/2024

Edition 01- Révision 01

Date : 24/09/23 - page 4/26

1.4. Cadre Applicatif

1.5. Contenu Du Document

La lecture de ces définitions constitue un prérequis indispensable pour la bonne

© OllcAvis - Master II GIL 2023/2024

Edition 01- Révision 01

Date : 24/09/23 - page 5/26

exigences techniques applicables à la conception et au développement du système

● Les exigences sont référencées selon le format suivant :

© OllcAvis - Master II GIL 2023/2024

Edition 01- Révision 01

Date : 24/09/23 - page 6/26

2. Exigences Fonctionnelles Et Opérationnelles

● Application Programming Interface (API) : Interface de programmation permettant

2.2. Généralités et missions du système

© OllcAvis - Master II GIL 2023/2024

Edition 01- Révision 01

Date : 24/09/23 - page 7/26

Le système «OllcAvis» devra s’interfacer avec la plateforme d’e-commerce Ollca ainsi

Les fonctionnalités devront être développées au travers d’IHMs dédiées et accessibles au

2.3. Rôle des utilisateurs

E_ROL_10 Le système «OllcAvis» définit trois rôles principaux :

● un rôle d’auteur : utilisateur ayant effectué une commande Ollca lui

E_ROL_20 L’accès aux fonctionnalités avancées du système (configuration des

E_ROL_30 L’accès aux fonctionnalités de modération (accepter / refuser un avis)

E_ROL_60 L’accès aux fonctionnalités de signalement d’avis suspect est possible

© OllcAvis - Master II GIL 2023/2024

Edition 01- Révision 01

Date : 24/09/23 - page 8/26

2.4. Module d’invitation

Les exigences ci-après sont applicables au module d’invitation.

E_INV_30 Lorsqu’une invitation est envoyée à un client, elle contient un résumé

E_INV_40 Le système «OllcAvis» écoute le topic Kafka “order” afin de récupérer

© OllcAvis - Master II GIL 2023/2024

Edition 01- Révision 01

Date : 24/09/23 - page 9/26

2.5. Module de rédaction d’avis

E_RED_10 Le système «OllcAvis» permet à un client de la plateforme Ollca

E_RED_20 Le système «OllcAvis» permet à un rédacteur de masquer son identité

E_RED_30 Le système «OllcAvis» permet à un rédacteur d’accéder à un

E_RED_40 Lors de la création d’un avis, le système «OllcAvis» présente de façon

E_RED_50 Lors de la création d’un avis, le système «OllcAvis» enregistre les

© OllcAvis - Master II GIL 2023/2024

Edition 01- Révision 01

Date : 24/09/23 - page 10/26

● la date de création de l’avis

E_RED_60 Le système «OllcAvis» permet à un rédacteur de lister ses avis et d’en

E_RED_70 Le système «OllcAvis» permet à un rédacteur, depuis la liste de ses

E_RED_80 Le système «OllcAvis» permet à un rédacteur, depuis la liste de ses