Plan de projet: Détection de subjectivité dans les news

IAFA-tigable - Responsable: OLEIWAN Joe

Contributeur: DELMOTE Adrien
Approbateur: MEUNIER Mortimer

13/01/2024

M1 Informatique
S8
UE Management de projet

Résumé

Dans le cadre du CLEF (Conferences and Labs of the Evaluation Forum) le laboratoire
« CheckThat ! » se concentre sur la détection de fake news. Divisé en plusieurs tâches
dont la tâche 2 : détecter la subjectivité dans des articles de presse. C’est cette tâche
sur laquelle notre équipe de Master informatique (IA et Systèmes embarqués) reprend
ce projet collaboratif en ciblant l’utilisation de méthodologies basées sur des Modèles de
Langage (LLM) et des dictionnaires. Le document fournit un aperçu détaillé du contexte,
des techniques et approches de gestion utilisées, soulignant les objectifs du projet ainsi que
son organisation.

Mots-clefs

-LLM-
-Recherche-
-Méthodes-
-Détection-
-Objectivité-
-Subjectivité-
-Dictionnaire-
-Développement-

1
 Table des matières

I Contexte et Objectif 3
I.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
I.2 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

II Parties prenantes 4
II.1 UE Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
II.1.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
II.2 Maître d’ouvrage - Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
II.2.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
II.2.2 Capture du besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
II.3 Assistants maître d’ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
II.3.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

III Organisation interne 6

III.1 Organisation du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
III.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
III.3 Suivi des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
III.4 Gestion des ressources et de la production . . . . . . . . . . . . . . . . . . . . . . . . . 7

IV Phase de Recherche 8
IV.1 Modèles et résultats des équipes de CLEF 2023 . . . . . . . . . . . . . . . . . . . . . . 8
IV.2 État de l’Art de la détection automatique de la subjectivité . . . . . . . . . . . . . . . 8
IV.3 Avancement de la recherche sur le prompt engineering . . . . . . . . . . . . . . . . . . 8

V Phase de développement 9

VI Contrôle Qualité 10
VI.1 Clarté de communication avec les parties prenantes . . . . . . . . . . . . . . . . . . . . 10
VI.2 Accessibilité des informations récoltées . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
VI.3 Accessibilité des travaux effectués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
VI.4 Clarté des livrables d’UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
VI.5 Clarté des livrables auprès du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

VII État actuel du projet 12

VII.1Référentiel de structure du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
VII.2Versions du Plan Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
VII.3Diagramme de Gantt actuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
VII.4Avancement de la recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
VII.5Avancement du développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
VII.6Check list d’autoévaluation PMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
VII.7Autres ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

VIIIBilan 13

2
 I – Contexte et Objectif

I.1 Contexte
Le laboratoire CheckThat ! a été organisé pour la 7ème reprise dans le cadre de CLEF 2024. Notre
but est d’examiner les travaux précédents et de réaliser la tâche 2 qui consiste à l’identification de la
subjectivité. L’objectif de cette tâche est de promouvoir l’intelligence artificielle dans le domaine de
la détection de fragments de texte subjectifs depuis des articles de presse ou tweets. La subjectivité
est une caractéristique du langage : en prononçant un énoncé le locuteur exprime simultanément sa
position, son attitude et ses sentiments à l’égard de celui-ci, laissant ainsi sa propre empreinte. Selon
le laboratoire, une phrase est considérée comme subjective si elle contient plusieurs critères tels que :
• Rapporter explicitement l’opinion personnelle de son auteur ;
• Contenir des expressions sarcastiques ou ironiques ;
• Contenir des exhortations ou des auspices personnels ;
• Contenir des expressions discriminatoires ou dévalorisantes ;
• Contenir des figures de rhétorique explicitement formulées par son auteur pour exprimer son
opinion ;
• Contenir une conclusion tirée par son auteur en dépit d’informations factuelles insuffisantes ;
• Contenir des intensificateurs qui peuvent être attribués à son auteur pour exprimer son opinion ;
(cf. On the Definition of Prescriptive Annotation Guidelines for Language-Agnostic Subjectivity Detection)

La tâche propose des corpus composés de 9 530 phrases annotées manuellement, couvrant six langues
- arabe, néerlandais, anglais, allemand, italien et turc.

I.2 Objectif
Il s’agira de développer des modèles basés sur de l’apprentissage automatique. Les modèles utilisés
pourront s’appuyer sur des technologies de type LLM (chatGPT, LangChain, etc.) et/ou sur d’autres
modèles de Machine Learning en se basant sur un dictionnaire de textes (ex. : les forêts aléatoires).
Les différents modèles et différentes configurations seront évalués (évaluation de l’efficacité) sur plu-
sieurs jeux de données labelisés.
Fonctionnalité minimale : Un modèle d’apprentissage profond présentant des résultats corrects sur
la langue anglaise, un rapport d’évaluation de la prédiction sera rendu ; plusieurs configurations du
modèle seront tester
Fonctionnalités complémentaires :
• D’autres modèles d’apprentissage sur une ou plusieurs langues différentes de l’anglais .

3
 II – Parties prenantes

II.1 UE Management
Présentation de l’UE : Faisant partie du programme de première année en Master Informatique,
l’Unité d’Enseigement (UE) Management de Projet encadre le projet de quatre mois que nous prenons
en charge, elle définit les aspects de gestion du projet et les évalue.
L’évaluation se fera tout au long de l’UE, avec des travaux que l’on doit aux professeurs de manage-
ment ; Dates et intitulés des livrables :
• Dépôt Rendu kick-off : 13 janvier 2024
• Dépôt Plan projet V1 : 17 février 2024
• Dépôt Plan projet V2 : 17 mars 2024
• Dépôt Plan project V3 : 14 avril 2024
• Dépôt Soutenance finale (Transparent) : avant fin avril 2024

II.1.1 Communication
La communication avec les responsables de l’UE management ce fait durant les cours de travaux
dirigés prévus ainsi qu’à travers un serveur Discord III.2 crée par les responsables pour échanger et
poser d’éventuelles questions.

II.2 Maître d’ouvrage - Client

Le Maître d’ouvrage (MO) est Mme. Josiane Mothe, Professeur en Système d’information, Big
Data, Recherche d’information, Exploration d’information et Apprentissage automatique à L’institut
de Recherche Informatique de Toulouse (IRIT). Responsable et contributrice à plusieurs projets au
cours des années, Mme Mothe nous a proposé ce sujet sur la détection de la subjectivité s’appuyant
sur la tâche 2 du CLEF 2023 et 2024 dont le but global est la détection de fake News.
Même si nos modèles répondent aux mêmes critères que ceux demandés pour participer au CLEF
2024, nous ne faisons qu’utiliser les informations et données mises à notre disposition.

II.2.1 Communication
Afin d’assurer une bonne communication avec le client, il a été conclu pendant la réunion de
lancement du projet que des réunions de 5 à 15 minutes seront faites en fin de journées sur chacun
des deux jours prévus pour le projet dans la semaine, lundi et mardi. Ces réunions rapides nous
permettent de tenir la cliente informée de l’avancement du projet et de définir dynamiquement les
tâches à effectuer par la suite. Elles sont transcrites dans un fichier log dédié sur le dépôt github Hors
des réunions, nous communiquons par mail avec tous les participants en copie (VI).

II.2.2 Capture du besoin

Lors d’une réunion de capture du besoin antérieure à celle de lancement du projet et dans nos
réunions bi-hebdomadaires, nous écoutons attentivement le client pour saisir ses besoins. Ces échanges
sont l’occasion d’ajuster notre compréhension et de préciser le projet. Un tableau récapitulatif est
utilisé pour tracer ces besoins, disponible dans le référentiel de structure de projet VII.1, assurant que
chaque point discuté est bien noté et sera suivi. Ce tableau, régulièrement mis à jour, sert de guide
pour le développement et assure que le produit final répondra aux attentes du client.

4
II.3 Assistants maître d’ouvrage
Les Assistants à la Maîtrise d’Ouvrage (AMO) M. Julien Contarin et M. Antoine Maîresse,
anciens étudiants de M1 ayant fait ce projet en 2023 peuvent avoir le rôle de valider une proposition
technique de notre part si besoin, de valider l’organisation du projet, d’accepter la gestion des risques
du projet, de proposer des éléments d’assurance et de contrôle qualité ou aussi de nous conseiller dans
les exigences à exprimer quant à la maintenabilité ou la pérennité du produit développé, d’assurer la
validation des livrables, de valider le référentiel projet.

II.3.1 Communication
La communication avec les Assistants maître d’ouvrage est établie à travers les mails échangés
avec le client ainsi que dans une section dédié sur le même serveur Discord que nous utilisons interne
(III.2) pour organiser des réunions de gestion projet.

5
 III – Organisation interne

III.1 Organisation du travail

Le projet se découpe en deux phases principales que nous abordons chacune avec leur propre
méthode de management de projet.
La première phase est la phase de recherche. Nous réalisons un État de l’Art des méthodes utilisées par
les équipes de l’année 2023, des recherches effectuées sur la détection automatique de la subjectivité
ainsi que l’avancement de la recherche sur les technologies qui pourraient nous être utiles (tel que le
prompt engineering). Afin de pouvoir aisément diriger nos recherches, nous adoptons ici une méthode
KanBan avec des discussions internes et avec le client de manière régulière.
Après avoir effectué le choix de technologie, nous basculeront vers une méthode AGILE pour mieux
convenir aux besoins de management dans la phase de développement. VII.1

Capture d’écran du Gantt initiale sur GanttProject

Nous avons aussi réaliser un Gantt initiale, dans le but de pouvoir nous organiser et avoir un "squelette"
sur les tâches que nous devons accomplir ainsi que le temps que nous estimons. Ce planning ainsi que
les plannings courants (évolutif) sont disponible dans le référentiel de structure du projet VII.1.

III.2 Communication
Afin de faciliter la communication interne, nous utilisons la plateforme de messagerie instantanée :
Discord. L’objectif de Discord est de nous permettre de communiquer rapidement et de se partager
des documents avant validation. Pour s’assurer que le serveur Discord reste organisé, chaque membre
du groupe a les permissions nécessaires afin de créer, remanier ou supprimer les canaux de discussion.
Au besoin, selon les tâches en cours, nous nous rassemblons en présentiel pour collaborer.

III.3 Suivi des tâches

Nous utilisons un outil de gestion de projet en ligne inspiré de la méthode KanBan : Trello. Il
nous permet d’indiquer les différentes tâches à faire, les tâches en cours ainsi que les tâches finies, afin
d’avoir un réel suivi sur le projet pour l’ensemble des membres du groupe. Le Trello nous sert aussi à
regrouper tous les points à aborder et les informations importantes transmises lors des réunions, avant
de les transcrire proprement dans les comptes-rendus de réunions II.2.1.
Référentiel de structure projet : Nous établissons un document Excel qui permet de sauvegarder la
structuration de projet au niveau OBS (Organisation Breakdown Structure), PBS (Project Breakdown

6
Structure), WBS (Work Breakdown Structure), diagramme de Gantt intial et un diagramme de gantt
que nous mettons à jour au fur et à mesure des besoins.

III.4 Gestion des ressources et de la production

Pour gérer nos ressources et nos productions, nous utilisons un système de contrôle de version
distribué populaire : github. Nous déposons dans ce dépôt tous les documents validés d’après nos règles
de qualité (cf.VI). La gestion automatique des versions fournie par git et github nous permettent de
pouvoir constamment accéder aux versions antérieures de chaque document. Le dépôt est visible
publiquement afin de permettre aux parties prenantes de pouvoir consulter les ressources qui les
intéressent.
Lien github : https://github.com/fghjklm/Projet_M1_CheckThat-
En parallèle, nous utilisons le logiciel Zotero afin de regrouper tous les articles potentiellement liés à
nos objectifs. Nous effectuons des synthèses de ceux nous semblant les plus pertinents qui se retrouvent
dans le dépôt git.

7
 IV – Phase de Recherche

IV.1 Modèles et résultats des équipes de CLEF 2023

CLEF : Conference and Labs of the Evaluation Forum.
L’accès aux rapports des équipes de CLEF 2023 est une opportunité de taille dans la réalisation de
notre projet. Nous explorons les méthodes ayant été utilisées et essayons d’en extraire les informations
utiles : les modèles, méthodes de fine-tuning ou les raisons des mauvais résultats de certaines équipes.

IV.2 État de l’Art de la détection automatique de la subjectivité

Nous effectuons également un état de l’art de la détection automatique de la subjectivité afin de
découvrir s’il existe des pistes différentes de celles explorées par les équipes de l’an dernier.

IV.3 Avancement de la recherche sur le prompt engineering

Lors de la phase développement, un élément essentiel dont nous aurons besoin est le prompt
engineering. Nous effectuons des recherches afin de trouver les méthodes les plus efficaces utilisées sur
des travaux de recherche précédents. L’objectif est de perfectionner les requêtes que nous formulerons
au LLM sélectionné dans le choix de technologie.

8
 V – Phase de développement

En construction - à établir dans une version future du Plan Projet.

9
 VI – Contrôle Qualité

Dans le but de mener à bien le projet, nous définissons plusieurs objectifs de qualité, tant sur la
qualité des livrables que sur la qualité de notre organisation générale.

VI.1 Clarté de communication avec les parties prenantes

1. Au préalable des réunions, résumer au maximum les informations obtenues dans la journée.
2. Lors des réunions, ne pas perdre de temps sur le son/écran fonctionnant mal. S’il y a un souci,
les autres participants l’indiqueront.
3. Lors des réunions, un seul interlocuteur de l’équipe résume l’ensemble et la personne concernée
détaille son point si demandé/nécessaire.
4. Le trello sert de référentiel pour le travail à effectuer, il doit être mis à jour avant ou après
chaque réunion.
5. S’il y a des remarques ou question à poser au client, elles doivent apparaître sur le Trello dans
l’onglet adéquat.
6. Template de compte-rendus de réunion à suivre.
7. Les mails doivent avoir une syntaxe [ IAFA-tigable ][Check that ! Subjectivity] objet et en copie
tout le monde ( CLient AMO et l’équipe).

VI.2 Accessibilité des informations récoltées

1. Tous les articles lus, même de manière incomplète, doivent apparaître sur Zotero.
2. Tout article utile au projet doit être synthétisé (au moins les informations utiles).
3. Le github contient la liste des articles utiles mais pas encore synthétisés.
4. Toutes les synthèses d’article doivent être dans le github.
5. Nom des commit github : écrits en minuscules et underscore à la place des espaces.
6. Clarté des synthèses :
(a) La synthèse doit suivre le Template de synthèse de lecture de papiers de recherche (Template
différent pour les compte-rendus des équipes 2023).
(b) Nom des synthèses des compte-rendus des équipes 2023 : "nom équipe" "quelques mots clef
(2/3)" "synthèse".
(c) Nom des synthèses d’articles scientifiques : "sujet article" "mots clef (2/3)" "synthèse".
(d) La synthèse d’un document lu doit contenir en haut de page le nom du lecteur afin de savoir
à qui s’adresser pour obtenir plus d’informations.
(e) Si possible, indiquer le paragraphe du document contenant l’information notée.
(f) Le lien vers l’article doit apparaît tout en haut de la synthèse.

VI.3 Accessibilité des travaux effectués

1. Le discord ne sert qu’à communiquer à un instantanément ou à montrer un document avant
qu’il soit validé. Après validation, il faut transférer les ressources dans l’endroit adéquat du
github.
2. Pour les documents nécessitant un logiciel (par exemple le gantt) : le format de base doit être
présent sur le github pour pouvoir le modifier aisément mais également une image (png ou jpeg)
afin que tous puissent le consulter facilement.
3. Règles du github (En construction).
4. Nom des commit github : écrits en minuscules et underscore à la place des espaces.

10
VI.4 Clarté des livrables d’UE
1. Cohérence des différentes parties du plan de projet.
2. Division correcte des parties du plan de projet.
3. Garder une trace des révisions effectuées et des anciennes versions des documents importants :
4. Plan projet écrit au présent.
5. Repasser une seconde fois par une personne différente, sur les documents écrits pour vérifier les
fautes d’orthographe.
6. Les documents suivants doivent être validés par au moins deux personnes qui ne les as pas
écrites avant d’apparaître sur le github : Gantt, compte-rendus de réunion.
7. Les documents suivants doivent être validés par tous à chaque version avant d’apparaître sur
le github : plan de projet, Référentiel de structure de projet.
8. La validation consiste en une réaction check vert sur Discord

VI.5 Clarté des livrables auprès du client

1. Repasser une seconde fois par une personne différente, sur les documents écrits pour vérifier les
fautes d’orthographe.
2. Les documents suivants doivent être validés par au moins deux personnes qui ne les as pas
écrites avant d’apparaitre sur le github : Gantt, compte-rendus de réunion.
3. Les documents suivants doivent être validés par tous à chaque version avant d’apparaître sur
le github :choix de technologie, les rapports intermédiaires de développement à rendre,
4. La validation consiste en une réaction check vert sur Discord dans le cas d’une conformité
totale.

11
 VII – État actuel du projet

Dans cette section, nous présentons des liens vers les ressources actuelles du projet, structurées
sur un dépôt github (cliquez sur les bouttons représentés par <- Boutton ->), vous y trouverez le
référentiel de structure du projet, le diagramme de Gantt, les différentes versions de ce document et
les avancements de la recherche et du développement.

VII.1 Référentiel de structure du projet

Le référentiel du plan projet, comprenant l’organisation de la structure à travers l’Organisation
Breakdown Structure (OBS), le Project Breakdown Structure (PBS), le Work Breakdown Structure
(WBS), est accessible ici : <- Référentiel projet ->

VII.2 Versions du Plan Projet

Les autres versions du Plan Projet sont accessibles ici : <- Plan Projet ->

VII.3 Diagramme de Gantt actuel

Vous pouvez consulter le diagramme de Gantt actuel pour suivre l’évolution du projet en utilisant
ce lien : <- Gantt ->

VII.4 Avancement de la recherche

Pour voir les progrès de notre recherche, veuillez consulter ce dossier : <- La Recherche ->

VII.5 Avancement du développement

L’avancement du développement du projet est disponible dans le dossier suivant : <- Le dévelop-
pement ->

VII.6 Check list d’autoévaluation PMP

Pour voir la check list d’autoévaluation, veuillez consultez ce dossier : <- CheckList ->

VII.7 Autres ressources

Toutes les autres ressources liées au projet, tels que les rapports intermédiaires, les documents de
conception, et les résultats des tests, sont également disponibles dans notre page GitHub.

12
 VIII – Bilan

En construction - à établir dans la version 3 du Plan Projet.

13