Cahier des Charges

Mise en place d’une application web pour l’analyse

de l’évolution des réseaux (personnels) sociaux en ligne (v. 1)

Titouan Bahon, Valentin Vincent, Hulduz Djanbekov

15 novembre 2023

1
Table des matières
1 Introduction 3
1.1 Remerciements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation générale du projet . . . . . . . . . . . . . . . . . . . 3
1.3 Description de l’entreprise cliente . . . . . . . . . . . . . . . . . . 3
1.4 Description et coordonnées de l’équipe . . . . . . . . . . . . . . . 3

2 Modèle du domaine/vocabulaire 3

3 Besoins fonctionnels 5
3.1 Description des utilisateurs . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2 Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Liste hiérarchisée des besoins du client . . . . . . . . . . . . . . . 7
3.2.1 MUST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2 SHOULD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.3 COULD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.4 WON’T . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Besoins non fonctionnels 9

4.1 Contexte technologique . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1 Choix du serveur . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2 Caractéristiques du site . . . . . . . . . . . . . . . . . . . 9
4.1.3 Contraintes judiciaires . . . . . . . . . . . . . . . . . . . . 9

5 Evolution potentielle des besoins 9

6 Limites du projet 9

7 Risques 9
7.1 Liste des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2 Matrice de criticité . . . . . . . . . . . . . . . . . . . . . . . . . . 10

8 Planning 10

9 Gestion de projet 10

10 Annexes : connaissances utiles 11

2
1 Introduction
1.1 Remerciements
Nous tenons à remercier Claudia Marinica ainsi que Fabien Picarougne, de
nous avoir conseillé et guidé durant la rédaction de ce document. Nous tenons
également à remercier Célia . . . et Sarra Djemili pour leurs travaux sur le sujet
que nous étudions, qui nous ont énormément servi lors de la rédaction du cahier
des charges.

1.2 Présentation générale du projet

L’équipe DUKe (Data User Knowledge) du LS2N a mis en place des algorithmes
et des approches grâce à l’aide de collègues en sciences humaines et sociales afin
d’étudier le comportement des individus dans des milieux culturels, aider les
experts du domaine à gérer leurs données etc. . . Actuellement, un programme
de recherche est en cours et traite de l’étude de l’évolution des réseaux sociaux
personnels en ligne et un outil en Java a été développé pour permettre d’étudier
ces derniers grâce à l’intégration de calculs d’un ensemble de métriques sur
les réseaux, ou bien l’application de modèles d’évolution permettant de prédire
l’état du réseau. L’objectif de ce projet est donc de réaliser une application
web en utilisant les outils déjà existants afin de faciliter l’analyse des réseaux
personnels présents pour les chercheurs de la communauté.

1.3 Description de l’entreprise cliente

Le LS2N (le Laboratoire des Sciences du Numérique de Nantes) a été créé en jan-
vier 2017 afin de renforcer la visibilité de la recherche en sciences du numérique
à Nantes. Elle est issue de la fusion entre l’ancienne UMR IRCCyN, l’institut
de recherche en communication et cybernétique, et le LINA, laboratoire d’in-
formatique de Nantes Atlantique. Avec plus de 500 collaborateurs répartis sur
5 sites, le LS2N est la plus grosse unité de recherche publique en région Pays de
la Loire.

1.4 Description et coordonnées de l’équipe

Nous sommes trois étudiants de 4ème année de l’école Polytech à Nantes dans
le département informatique. AJOUTER COORDONNEES

2 Modèle du domaine/vocabulaire
Un réseau personnel fait référence à la structure de relations interpersonnelles,
c’est un ensemble de liens entre un ensemble défini de personnes. Les liens dans
leurs ensemble peuvent être utilisés pour interpréter le comportement social.

Un réseau social personnel peut être représenté par un graphe G (V,E)

3
où V est l’ensemble de nœuds représentant les acteurs sociaux et E l’ensemble
des arêtes représentant les liens entre eux.

Une métrique est une mesure utilisée pour évaluer ou caractériser divers as-
pects des réseaux sociaux personnels.

Il y a donc plusieurs métriques :

La densité : mesure combien d’arêtes se trouvent dans l’ensemble E par rapport

au maximum d’arêtes possible parmi les nœuds . D= (2xm)/(nx(n-1)) où m est
le nombre d’arêtes et n est le nombre de noeuds du réseau

Clustering coefficient : mesure dans quelle mesure les nœuds d’un graphique
ont tendance à se regrouper . Il existe trois versions :

Local Clustering Coefficient : calcule la transitivité dans le voisinage d’un

nœud donnée. LCC(v) = (2xmv)/(deg(v)(deg(v)-1)) où mv est le nombre d’arêtes
entre voisin de v et degv est le degré de v.

Average Clustering Coefficient : calcul la moyenne des coefficients de clus-

tering locaux dans l’ensemble des nœuds à l’intérieur du réseau.

Local Clustering Coefficient : Donne une mesure du regroupement des voi-

sins d’un nœud. Soit LCC(v) le Local Clustering Coefficient du nœud v, alors
P
v∈V LCC(v)
LCC =
n
où n est le nombre de nœuds.
Global Clustering Coefficient : Donne une indication sur le regroupement
dans le réseau en prenant en compte le nombre de triangles dans le graphe et
le nombre de triplets. Un triplet se compose de trois nœuds connectés, et un
triangle comprend trois triplets fermés. Cela forme un triangle. La formule est
donnée par

3×T
GCC =
C
où T est le nombre de triangles et C est le nombre de triplets.

On a aussi plusieurs mesures de Centralité :

Degré de centralité : Le nombre d’arêtes que possède le nœud. Un nœud

avec le plus fort degré est le nœud central. Closeness centrality : Le nœud le
plus central est celui qui est le plus proche de tous les autres nœuds. La formule
est donnée par

4
 1
C(u) = P
v d(v, u)

où d(v, u) est la distance entre les sommets v et u.

Betweenness centrality : Le nœud le plus central est celui où la plupart

des chemins passent pour aller d’un nœud à un autre.

X Sv,w (u)
B(u) =
Sv,w
u̸=v̸=w

où Sv,w est le nombre de chemins les plus courts entre v et w dans un graphe
G, et Sv,w (u) est le nombre de nœuds qui passent par u.

Le temps d’exécution est la durée que prend un algorithme à s’exécuter et à

renvoyer un résultat exploitable

3 Besoins fonctionnels
Le projet en cours consiste à produire une application web prenant un réseau
personnel en données afin d’afficher un graphique analysant ces données grâce
aux différentes métriques énoncées ci-dessus. Les utilisateurs de cette applica-
tion seront des chercheurs ou toute personne souhaitant avoir des données et
des analyses sur des réseaux personnels.

On souhaite rendre l’application utilisable rapidement par les ut

3.1 Description des utilisateurs

3.1.1 Introduction
Les utilisateurs sont assez globaux, ces utilisateurs sont des individus qui veulent
regarder des réseaux personnels de n’importe quel domaine et de n’importe quel
réseau.

5
3.1.2 Personas
Nom Marie Dupont
Profession Enseignante en Sciences Sociales
Enseignante passionnée de sciences sociales,
elle utilise le site pour illustrer des concepts
de réseaux sociaux en classe. Elle cherche
des fonctionnalités conviviales pour visuali-
Description
ser les relations et les métriques de réseaux
sociaux, elle apprécierait des fonctionnalités
de présentation pour faciliter l’explication aux
étudiants.
Nom Maxime Lambert
Profession Etudiant en sociologie
Maxime utiliserait le site pour analyser les
réseaux sociaux dans le cadre de ses re-
cherches. Il a besoin d’outils avancés pour cal-
culer des métriques spécifiques, comme la cen-
Description tralité des nœuds et souhaite pouvoir importer
facilement des métriques spécifiques, comme la
centralité des nœuds et souhaite pouvoir im-
porter facilement des données depuis d’autres
sources.
Nom Sarah Martin
Profession Responsable des ressource humaine
Souhaite utiliser le site pour visualiser les
connexions au sein de l’entreprise. Elle est
intéressée par la fonctionnalité d’importation
Description de données depuis des plateformes profes-
sionnelles comme LinkedIn et cherche des
métriques qui peuvent aider à identifier des
leaders.
Nom Alex Dubois
Profession Chercheur en Informatique
Alex utilise le site pour tester des algorithmes
de calcul de métriques sur des ensembles de
données complexes. Il souhaite une interface
Description qui permet d’importer des données personna-
lisées, d’ajuster les paramètres des calculs, et
de visualiser les résultats de manière détaillée
pour ses expérimentations.

6
3.2 Liste hiérarchisée des besoins du client
3.2.1 MUST
Fonctions Critères
Le but est de récupérer le dépôt Git de Célian
Rolland ensuite de comprendre son code ainsi
que évalué la qualité de son implémentation. Le
Prise en main du
second but est d’évalué l’utilisation des frame-
précédent projet
work utiliser par Céliant Rolland et si besoin
trouver un nouveau framework plus adapté au
projet.
L’objectif est d’extraire les réseaux personnels
d’un réseau à une profondeur donnée à un mo-
Extraire les réseaux per- ment t, puis, pour le même réseau et la même
sonnels profondeur, extraire les réseaux personnels à
t+1. Cette extraction permet de voir l’évolution
des reseaux personnels.
La fonctionnalité de chargement de réseaux
personnels permet à l’utilisateur d’intégrer ses
propres réseaux personnels dans l’application.
Possibilité de charger ses
En chargeant ses propres réseaux, l’utilisateur
propres réseaux pour l’uti-
peut exploiter des données qui lui sont direc-
lisateur
tement pertinentes, optimisant ainsi l’utilité et
la pertinence de l’application pour ses objectifs
individuels.
Le calcul des métrique permet d’évaluer un re-
seau personnel sous plusieurs angles. Ces nom-
Calculer les métriques
breuses métriques sont à disposition afin d’affi-
ner la compréhension des reseaux.
Faire attention au temps nécessaire à l’exécution
de chacunes des métriques : évaluer le temps
Calculer efficacement les d’exécution sur ce qui existe déjà dans l’appli-
métriques cation web codée par Célian et essayer de mini-
miser au maximum ce temps pour les métriques
les plus longues à calculer.
Réfléchir à comment afficher les métriques de
Afficher les résultats des
façon claire et rapide sur l’interface de l’appli-
métriques
cation web.

7
3.2.2 SHOULD
Fonctions Critères
Certaines métriques peuvent prendre du temps
à se calculer surtout si le réseau à étudier est
d’une grande longueur. Nous avons donc deux
Savoir gérer les calculs choix qui s’opposent à nous : demander à l’uti-
avec un temps d’exécution lisateur d’attendre et de revenir plus tard sur la
lent page web lorsque la métrique aura été calculée
pour tous les réseaux personnels, ou afficher au
fur et à mesure sur le graphique les métriques
des réseaux personnels calculées.
L’affichage des graphiques devra s’adapter à la
Adapter l’affichage des demande de l’utilisateur : on devra pouvoir zoo-
graphiques mer sur des groupes de points en choisissant le
maximum et le minimum de chacun des axes.

3.2.3 COULD
Fonctions Critères
Adapter l’affichage du L’utilisateur devra avoir le choix d’afficher ses
graphique à la temporalité résultats année par année, ou bien sur un inter-
choisie par l’utilisateur valle de temps personnalisé.
Avoir un système d’au- Les utilisateurs devront pouvoir se connecter à
thentification leur espace personnel.
L’application devra inclure la possibilité de sau-
Pouvoir sauvegarder les vegarder les analyses effectuées afin que l’utili-
analyses effectuées sateur puisse les retrouver plus tard dans son
espace personnel.
Avoir une application res- L’application devra être adaptée à l’utilisation
ponsive sur mobile ou tablette.
- L’affichage du graphique devra s’adapter à plusieurs types de visualisations
temporelles, que l’utilisateur choisira

3.2.4 WON’T
Fonctions Critères
Nous ne traiterons pas la fonctionnalité permet-
Intéractivité de l’applica- tant d’intéragir avec les points des graphiques :
tion passer sa souris sur un point doit permettre
d’avoir plus de détails sur ce dernier.
Inventer de nouvelles
métriques
Nous ne traiterons pas la récolte des données :
Faire le grab des données ces dernières devront être fournies par l’utilisa-
teur directement.

8
4 Besoins non fonctionnels
4.1 Contexte technologique
4.1.1 Choix du serveur
Le choix du serveur est très important, il faut choisir un serveur avec les bonnes
caractéristiques technique et logicielle. Nous avons besoin d’un serveur qui puisse
faire de gros calcul en un minimum de temps. Pour ce qui est de la limite de
personne qui peuvent se connecter simultanément au serveur, il n’y a pas besoin
que celle-ci soit extrêmement grande.

4.1.2 Caractéristiques du site

Le but de ce projet est que n’importe quel utilisateur qui veut étudier ces
réseaux personnels puisse le faire avec cet outil. Il est donc nécessaire que le
référencement SEO soit le plus optimal possible pour que l’outil soit le plus
facilement trouvable lors d’une recherche internet.

4.1.3 Contraintes judiciaires

Du aux réglementations mises en place depuis 2016 dans l’Union Européen, il
est nécessaire que ce site soit soumis au Réglement Générale sur la Protection
des Données (RGPD) vu que celui-ci est à destination du public.

5 Evolution potentielle des besoins

- Pouvoir appliquer sur les données différents modèles d’évolution, tester, évaluer
les résultats

- Rendre l’interface plus intuitive

6 Limites du projet
- Le projet ne couvrira pas toutes les questions et les problèmes que la juridic-
tion française peut provoquer

- Si de nouvelles métriques doivent être implémentées, ces dernières ne le se-

ront pas durant le projet

7 Risques
7.1 Liste des risques
— R1 : Contrainte de temps, rendu du projet à la fin de l’année.

9
 — R2 : Produire une application peu ergonomique (pas le temps de faire
des tests utilisateurs sur l’ergonomie)
— R3 : Prendre du retard sur une tâche
— R4 : Indisponibilité des membre du groupe

7.2 Matrice de criticité

Risque Improbable Peu probable Probable Très probable
Majeur R2
Grave
Moyen R1, R4 R3
Mineur

8 Planning
— 15/10/23 : Rendu brief
— du 15/10/23 au 18/11/23 : Approfondissement du sujet et rédaction du
cahier des charges ainsi que du premier rapport
— 19/11/23 : Rendu du cahier des charges
— 19/11/23 : Rendu de la première version du rapport
— 20/11/2023 : Première soutenance
— du 21/11/2023 au 29/11/2023 : Premier sprint découverte de l’interface
déjà existante
— 30/11/23 : Réunion
— du 01/12/23 au 13/12/23 : Deuxième sprint, début de codage et de re-
cherche d’amélioration du code existant
— 14/12/23 : Réunion
— du 15/12/23 au 11/01/24 : Troisième sprint, amélioration du frontend de
l’application web
— 12/01/24 : Réunion
— du 13/01/24 au 24/01/24 : Quatrième sprint, rédaction de la seconde
version du rapport et amélioration du code
— 25/01/24 : Réunion
— du 26/01/24 au 10/02/24 : Cinquième sprint, revue du rapport et amélioration
de la complexité du code
— 11/02/24 : Rendu de la seconde version du rapport
— semaine du 12 au 16/11/24 : Deuxième soutenance
— 21/04/24 : Rendu de la troisième version du rapport
— semaine du 29/04 au 03/05/24 : Soutenance final
— 12/05/24 : Rendu du rapport final

9 Gestion de projet
Le client nous a fourni plusieurs documents pour le commencement du projet.
Tout d’abord nous avons eu la thèse de Sarah Djemilietal qui est à la base

10
du projet. Les documents de la thèse nous ont été fournis sur un serveur de
UNCLOUD. Un git nous as également été fournis par le client, celui de Célian
Rolland, ce git contient des premier élément pour une interface sur ce sujet.

Nous avons fourni de nombreux documents au client. Tout d’abord nous avons
fournis et allons fournir toutes les semaine une rapport hebdomadaire de l’avan-
cement du projet, des problème renco ntrer et des prochaine tache à effectuer.
Nous avons également fournis un Brief qui resume les différent étape du pro-
jet avec ses contrainte, ses étapes et ses attente. Enfin le cahier des charges va
également etre fournis au client.

10 Annexes : connaissances utiles

11