Plan de projet: Détection de subjectivité dans les news
IAFA-tigable - Responsable: OLEIWAN Joe
Contributeur: DELMOTE Adrien
Approbateur: MEUNIER Mortimer, MOUYSSET Martin, BIENASSIS Jules
09/04/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 Version 4
II Contexte et Objectif 5
II.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
II.2 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
III Parties prenantes 6
III.1 UE Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
III.1.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
III.2 Maître d’ouvrage - Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
III.2.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
III.2.2 Capture du besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
III.3 Assistants maître d’ouvrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
III.3.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
IV Organisation interne 8
IV.1 Organisation du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
IV.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
IV.3 Suivi des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
IV.4 Gestion des ressources et de la production . . . . . . . . . . . . . . . . . . . . . . . . . 9
V Phase de Recherche 10
V.1 Modèles et résultats des équipes de CLEF 2023 . . . . . . . . . . . . . . . . . . . . . . 10
V.2 Avancement de la recherche sur le prompt engineering . . . . . . . . . . . . . . . . . . 10
VI Phase de développement 11
VI.1 Choix de technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
VI.2 Pré-traitement et Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
VI.3 Fine-tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
VI.3.1 Sur les jeux de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
VI.3.2 Prompt engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
VI.4 Génération et Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
VI.5 Démarches à venir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
VIIContrôle Qualité 12
VII.1Clarté de communication avec les parties prenantes . . . . . . . . . . . . . . . . . . . . 12
VII.2Accessibilité des informations récoltées . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
VII.3Accessibilité des travaux effectués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
VII.4Clarté des livrables d’UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
VII.5Clarté des livrables auprès du client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
VIIIÉtat actuel du projet 14
VIII.1Tableau d’organisation Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
VIII.2Référentiel de structure du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
VIII.3Versions du Plan Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
VIII.4Diagramme de Gantt actuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
VIII.5Avancement de la recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
VIII.6Avancement du développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
VIII.7Check list d’autoévaluation PMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2
VIII.8Autres ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
IX Bilan 15
IX.1 Méthode de rédaction du Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3
I – Version
Tableau des versions
Version Modification
Version 1 Ajout des parties Contexte et Objectif, Parties prenantes, or-
ganisation interne, Phase de recherche, Etat actuel du projet
Version 2 Ajout des parties Phase de développement et Contôle Qua-
lité
Version 3 Ajout de la partie Bilan et de la partie Version et modifica-
tion de la partie Contrôle qualité
4
II – Contexte et Objectif
II.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 des 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 CheckThat, 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.
II.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 testées.
Fonctionnalités complémentaires :
• D’autres modèles d’apprentissage sur une ou plusieurs langues différentes de l’anglais .
5
III – Parties prenantes
III.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
III.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 IV.2 créé par les responsables pour échanger et
poser d’éventuelles questions.
III.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 sans participer
à l’initiative.
III.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 seraient 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 (VII).
III.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 échangeons avec 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 VIII.2, assurant que chaque
point discuté soit 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éponde aux attentes du client.
6
Pour gérer les évolutions des besoins du client, nous barrons sur le tableau les besoins annulés, et nous
ajoutons les besoins révisés en vert sur le même tableau en vert.
III.3 Assistants maître d’ouvrage
Les Assistants à la Maîtrise d’Ouvrage (AMO) M. Julien Contarin et M. Antoine Maîresse,
étudiant en M2 ayant fait un 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.
III.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
(IV.2) pour organiser des réunions de gestion projet.
7
IV – Organisation interne
IV.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 basculerons vers une méthode AGILE pour mieux
convenir aux besoins de management dans la phase de développement. VIII.2
État de la méthode appliquée en phase de développement :
Capture d’écran du Gantt initiale sur GanttProject
Nous avons aussi réalisé un Gantt initial, dans le but de pouvoir nous organiser et d’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 disponibles dans le référentiel de structure du projet VIII.2.
IV.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.
Dans le cadre de la méthode de gestion KanBan, nous nous réunissons chaque matin afin de planifier
les tâches à effectuer, analyser les priorités et répartir rôles de chacun pour la journée. Cela se complète
avec la réunion du soir qui s’effectue avec le client. Pendant cette réunion nous l’informons de l’avancée
du projet et des tâches que nous pensons aborder le lendemain. Cette organisation nous permet de
constamment et rapidement adapter les ressources disponibles avec le flux de travail.
8
IV.3 Suivi des tâches
Nous utilisons un outil de gestion de projet en ligne inspiré de la méthode KanBan : Trello VIII.1.
Il nous permet d’indiquer les différentes tâches à faire, les tâches en cours ainsi que les tâches terminées,
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 retranscrire proprement dans les comptes-rendus de réunions III.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
Structure), WBS (Work Breakdown Structure), diagramme de Gantt initial et un diagramme de Gantt
que nous mettons à jour au fur et à mesure des besoins.
IV.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.VII). 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.
9
V – Phase de Recherche
V.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.
V.2 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.
10
VI – Phase de développement
VI.1 Choix de technologie
Suite à la phase de recherche, nous établissons un rapport de choix de technologie. Ce dernier est
consultable ici : [Choix technologique]. Le modèle de classification à développer se base sur le LLM
open-source choisi : Mistral 7B, un modèle pré-entrainé, performant et utilisant peu de paramètres.
VI.2 Pré-traitement et Implémentation
À cette étape, nous formattons nos données pour qu’elles soient utilisables avec le modèle dans un
premier temps. Ensuite, nous réalisons des tests révélateurs de pistes d’amélioration de nos jeux de
données.
Afin d’avoir accès aux ressources matérielles nécessaires, l’implémentation et les tests du modèle se
font sur la plateforme OSIRIM. Ainsi, l’environnement de travail et une petite documentation <lien>
sont à faire.
VI.3 Fine-tuning
VI.3.1 Sur les jeux de données
À la suite de l’implémentation, nous procédons à l’ajustement fin de Mistral7B sur notre jeu de
données spécifique pour améliorer son efficacité dans la tâche de classification de phrases objectives et
subjectives. Cette étape peut nécessiter plusieurs cycles d’entraînement et de validation.
VI.3.2 Prompt engineering
Nous utilisons les méthodes de prompt engineering consultées en recherche afin d’améliorer la descrip-
tion de la tâche à effectuer dans le but d’améliorer les résultats obtenus.
VI.4 Génération et Analyse des résultats
Le score de notre modèle est évalué grâce à la précision, la recall et le F1-score. Les démarches
suivies, les paramètres sélectionnés et les scores obtenus sont détaillés dans des rapports livrés au
client Rapports de développement.
Cette analyse permet de comprendre les forces et les faiblesses du modèle dans des contextes variés,
et contribue à la validation de son efficacité. Les résultats peuvent également révéler des pistes pour
des améliorations ultérieures ou pour l’adaptation du modèle à des cas d’utilisations similaires.
Cette étape est faite en mode itératif : On essaye d’améliorer les résultats à chaque analyse de la
génération précédente.
VI.5 Démarches à venir
Selon les résultats obtenus et l’analyse de la performance de Mistral7B, deux voies peuvent être
envisagées : si le modèle répond aux attentes et satisfait les exigences du client, nous pourrons procéder
à la validation et la clôture du sujet. Si, en revanche, les résultats s’éloignent des attentes, nous
envisagerons l’évaluation et potentiellement l’implémentation d’autres modèles. Cette décision sera
basée sur une analyse approfondie des performances de Mistral7B, en prenant en compte les retours
du client et des contraintes de temps.
11
VII – 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.
VII.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).
VII.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.
(g) Les synthèses doivent être au format texte pour permettere à tous de pouvoir les lire et
modifier si besoin
(h) toujours mettre .txt à la fin d’un fichier texte
(i) pas d’accent dans les titres de dossier et fichiers
VII.3 Accessibilité des travaux effectués
1. Le discord ne sert qu’à communiquer à un instant donné 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.
12
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. Nom des commit github : écrits en minuscules et underscore à la place des espaces.
4. Les synthèses doivent être au format texte pour permettere à tous de pouvoir les lire et modifier
si besoin
5. toujours mettre .txt à la fin d’un fichier texte
6. pas d’accent dans les titres de dossier et fichiers
VII.4 Clarté des livrables d’UE
1. Le plan projet ne doit contenir que les informations fixes.
2. Chaque document pouvant évoluer doit être pointé par un lien dirigeant vers le bon dossier du
github. Idem pour le(s) Trello(s).
3. Le plan projet doit être écrit au présent.
4. Chaque document livré devra être revu par une autre personne afin de s’assurer qu’il n’y ai pas
de faute de Français.
5. 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.
6. 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.
7. La validation consiste en une réaction check vert sur Discord.
VII.5 Clarté des livrables auprès du client
1. Chaque document transmis devra être revu par une autre personne afin de s’assurer qu’il n’y
ai pas de faute de Français.
2. Les points de qualité du code à fournir sont consultables ici : Controle qualité code .
3. Les critères d’évaluation de la qualité des modèles construits sont consultables ici : Critère
d’évaluation.
4. 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.
5. Les documents suivants doivent être validés par tous à chaque version avant d’apparaître sur
le github : le choix de technologie, les rapports intermédiaires de développement à rendre.
6. La validation consiste en une réaction check vert sur Discord dans le cas d’une conformité
totale.
13
VIII – É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
l’avancement de la recherche et du développement.
VIII.1 Tableau d’organisation Trello
Le tableau d’organisation sur lequel nous définissons au fur et à mesure les tâches à effectuer est
disponible ici : <- Trello ->
VIII.2 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 ->
VIII.3 Versions du Plan Projet
Les autres versions du Plan Projet sont accessibles ici : <- Plan Projet ->
VIII.4 Diagramme de Gantt actuel
Vous pouvez consulter le diagramme de Gantt actuel pour suivre l’évolution du projet en utilisant
ce lien : <- Gantt ->
VIII.5 Avancement de la recherche
Pour voir l’état de notre recherche, veuillez consulter ce dossier : <- La Recherche ->
VIII.6 Avancement du développement
L’avancement du développement du projet est disponible dans le dossier suivant : <- Le dévelop-
pement ->
VIII.7 Check list d’autoévaluation PMP
Pour voir la checklist d’auto-évaluation, veuillez consultez ce dossier : <-CheckList ->
VIII.8 Autres ressources
Toutes les autres ressources liées au projet, tels que les rapports intermédiaires et les résultats
des tests, sont également disponibles dans notre page GitHub : <- GitHub ->
14
IX – Bilan
IX.1 Méthode de rédaction du Bilan
Le Bilan est fait avec tous les membres du groupe. Nous regroupons l’ensemble des informa-
tions/remarques de l"équipe afin de les synthétiser. Le Bilan est constitué de plusieurs parties. Dans
un premier temps, nous parlons de notre projet et de son état final. Ensuite, nous analysons le dérou-
lement du projet dans sa globalité, nous parlons de nos choix dans le déroulement et nos problèmes
rencontrés. Par la suite, un avis succinct de l’équipe sur le travail réalisé. Et pour finir, les leçons
apprises tout au long du projet.
Vous trouverez le lien du Bilan : <-Bilan->
15
