Mémoire de Master — Analyse et questions d'examinateur

Candidat : HOUESSOU Gbénankpon Eros  ·  Parcours : Master Génie Informatique, UFR-SFA, Université Nangui Abrogoua  ·  Année : 2025-2026
Thème : Conception et développement d'une application web de synthèse automatique d'articles de presse en français basée sur un modèle Transformer pré-entraîné
Volume : 64 pages · 3 chapitres · 28 références + 6 webographie · 1 annexe

1. Appréciation générale

Mémoire bien construit et honnête. La chaîne de valeur est complète et cohérente : état de l'art → choix argumenté de BARThez → réglage fin sur MLSUM → évaluation ROUGE/BERTScore → API FastAPI → interface Next.js → conteneurisation Docker. La rédaction est fluide, les figures sont commentées (ce qui est rare et appréciable), et le candidat reconnaît lui-même ses limites (échantillon de 100 exemples, graine unique, absence d'intervalle de confiance, hallucinations non corrigées) — signe de maturité scientifique.

La faiblesse principale n'est pas la rédaction mais la robustesse du protocole expérimental et la modestie de l'apport scientifique original : il s'agit d'un fine-tuning standard d'un modèle existant sur un corpus existant, encapsulé dans une architecture logicielle classique. La contribution est essentiellement d'ingénierie — ce qui est légitime pour un parcours Génie Informatique, à condition que le candidat l'assume explicitement et n'oversell pas les résultats.

2. Analyse de la forme

2.1 Points forts

2.2 Défauts de forme à signaler

PointConstatGravité
Titre tronqué en couvertureLa page de garde affiche « … basée sur un modèle transformer pré-entrain » : le mot est coupé et la casse de « Transformer » est incohérente avec le reste du document. Un titre tronqué sur la page de garde d'un mémoire soutenu est le premier défaut que verra le jury.Majeure
Rendu typographiqueLe texte extrait présente de très nombreuses agglutinations de mots (« leursprièressilencieuses », « ilsontsoutenu »). À vérifier sur le PDF imprimé : s'il s'agit d'un problème réel de police/encodage LaTeX et non d'un artefact d'extraction, c'est éliminatoire pour un document officiel.À vérifier
Ligne « Examinateur » vide — non retenuPage de garde : « M. …………… Maître-assistant, UNA Examinateur ». Ne pas retenir comme reproche : l'examinateur n'est désigné qu'après le dépôt, le candidat ne pouvait pas le renseigner. Même situation dans les trois mémoires du jury.—
Déséquilibre des chapitresCh. 1 : 7 p. — Ch. 2 : 12 p. — Ch. 3 : 27 p. Le chapitre 3 mélange conception UML, environnement, corpus, entraînement, évaluation, analyse d'erreurs et déploiement. Il aurait dû être scindé en « Conception/Implémentation » et « Expérimentation/Résultats ».Moyenne
Tableau 3.1 (14 diagrammes UML)Le tableau liste les 14 diagrammes UML 2.x alors que 4 seulement sont utilisés. Contenu de cours, non contributif — typiquement le genre de remplissage que le jury relève.Mineure
Figures 3.5, 3.7, 3.8Ce sont des captures de code source présentées comme figures. Le code devrait figurer en listing formaté (comme le Listing 1 de l'annexe) ou en annexe, pas comme illustration.Mineure
Absence de pagination des annexes / d'un indexUne seule annexe (dépendances Python), qui aurait pu être un simple tableau en section. Aucun extrait de code du backend ni du script d'entraînement en annexe alors que c'est le cœur du travail.Mineure
Aucun lien vers le dépôt de codeLe mémoire décrit des scripts (fine_tune.py, evaluate_model.py, download_assets.py) sans donner d'URL de dépôt ni de commit — la reproductibilité est nulle.Moyenne

3. Analyse du fond — pertinence scientifique

3.1 Ce qui est solide

3.2 Faiblesses et incohérences relevées à interroger

A. Incohérence sur le volume de données d'entraînement.
La Figure 2.8 annonce « MLSUM (5000 ex.) » pour la phase de réglage fin. Le §3.4.2 indique TRAIN_SAMPLES=0, c'est-à-dire « corpus d'apprentissage complet » (392 902 paires). La Figure 3.7 présente en revanche le mécanisme de sous-échantillonnage. Trois versions différentes coexistent dans le même document.

B. Contamination du corpus non discutée.
Le §3.4.2 précise que le script « ajoute également xlsum comme corpus complémentaire par défaut via EXTRA_DATASETS, sauf si cette variable est explicitement vidée ». Le titre, le résumé, l'abstract et toute la section résultats affirment pourtant un fine-tuning « sur MLSUM ». Vérification arithmétique : 26 437 pas × 16 = 422 992 exemples par époque, contre 392 902 dans MLSUM-fr. L'écart de ~30 000 exemples confirme que xlsum a bien été mélangé. Cela invalide partiellement la comparabilité avec les scores publiés sur MLSUM.

C. Configuration d'évaluation ≠ configuration déployée.
Le système en production génère avec min_new_tokens=25, max_new_tokens=128. Le script d'évaluation force min_new_tokens=10 « afin d'obtenir des résumés suffisamment concis pour l'évaluation automatique » (§3.7.1). Or la longueur de génération influence mécaniquement le rappel et donc le F1 ROUGE. Les scores publiés ne mesurent donc pas le système livré, et le choix ressemble à un ajustement favorable à la métrique.

D. Le gain « avant/après » est trivialement acquis.
Le « BARThez de base » (Tab. 3.7) est un modèle de débruitage, jamais entraîné à résumer. Comparer un modèle fine-tuné à un modèle non entraîné pour la tâche ne démontre rien d'autre que « le fine-tuning fonctionne ». Aucune baseline sérieuse (Lead-3 recalculée, TextRank, LexRank, mBARThez, mT5) n'a été exécutée par le candidat lui-même — il l'admet en limites, mais c'est le point faible central du chapitre expérimental.

E. Le dépassement de Lead-3 n'est pas significatif.
20,37 vs 19,69 en ROUGE-L, soit +0,68 point, mesuré sur 100 exemples, avec une graine unique, sans intervalle de confiance, et avec une implémentation ROUGE différente de celle du benchmark (pas de racinisation). Cette conclusion — « notre modèle dépasse la baseline extractive » — ne tient pas statistiquement.

F. Perte d'entraînement non monotone, non commentée.
Tab. 3.5 : 2,902 → 2,791 → 2,856 → 2,811 → 2,814. Le texte ne commente que la validation. La remontée à l'époque 3 mérite explication (ordonnanceur cosinus ? lissage d'étiquettes ? reprise de checkpoint ?).

G. Erreur de modélisation UML.
Dans la Fig. 3.1, « Modèle BARThez » est représenté comme acteur du diagramme de cas d'utilisation. Un composant interne au système ne peut pas être un acteur : par définition un acteur est extérieur au périmètre du système. Confusion classique acteur/composant.

H. Zone morte du chapitre 1.
Sept pages sur RNN, BRNN, LSTM, GRU, disparition du gradient — technologies que le travail n'utilise pas. Ce contenu se justifie comme généalogie de l'attention, mais son poids est disproportionné par rapport au traitement du Transformer lui-même.

I. Sécurité applicative absente.
L'endpoint /extract-url télécharge une URL arbitraire fournie par l'utilisateur, côté serveur : c'est un vecteur SSRF classique (accès aux métadonnées cloud, au réseau interne Docker, au localhost). Aucune authentification, aucune limitation de débit, aucun quota, alors que chaque requête déclenche une inférence GPU. Le §3.1 ne mentionne que le filtrage des requêtes vides et le CORS.

J. Aucun test automatisé.
Aucun test unitaire, aucun test d'intégration, aucune CI n'est mentionné, alors que le mémoire revendique la maintenabilité comme exigence non fonctionnelle (§3.1).

4. Questions pour la soutenance

Ordre suggéré : ouvrir sur des questions de compréhension pour mettre le candidat en confiance, puis resserrer sur le protocole, puis ouvrir sur la prospective.

4.1 Questions d'ouverture — vérification de la maîtrise niveau 1

Q1. Vous avez retenu l'approche abstractive plutôt qu'extractive. Dans un contexte de presse, où la fidélité factuelle est critique et où vous documentez vous-même des hallucinations, l'approche extractive n'aurait-elle pas été le choix le plus défendable ? Qu'est-ce qui, concrètement, justifie de prendre ce risque ? Attendu : arbitrage lisibilité/fluidité vs garantie factuelle ; reconnaissance que le choix est discutable pour ce cas d'usage.
Q2. Expliquez au jury, sans formule, pourquoi un modèle purement encodeur comme CamemBERT ne peut pas produire un résumé abstractif, alors que BARThez le peut. Attendu : absence de décodeur autorégressif, pas de génération token par token, pas d'attention croisée, pas d'objectif de génération conditionnelle au pré-entraînement.
Q3. Votre équation 2.1 fait apparaître un facteur 1/√dk. À quoi sert-il précisément, et que se passerait-il si on l'omettait ? Attendu : produit scalaire de variance croissante avec dk → softmax saturé → gradients quasi nuls. Question de vérification que le candidat n'a pas simplement recopié l'article.
Q4. Vous utilisez no_repeat_ngram_size=3 et repetition_penalty=1.3. Dans un article de presse où un nom propre ou un chiffre doit légitimement être répété, quel effet indésirable ces contraintes peuvent-elles produire ? Avez-vous mesuré cet effet ?

4.2 Questions sur le protocole expérimental niveau 2 — cœur de l'évaluation

Q5. [Incohérence B — question centrale] Votre §3.4.2 indique que le script ajoute xlsum par défaut aux données d'entraînement. Or votre titre, votre résumé et l'ensemble de vos résultats annoncent un fine-tuning « sur MLSUM ». Par ailleurs, 26 437 pas × 16 = 422 992 exemples par époque, contre 392 902 dans la partition française de MLSUM. Confirmez-vous que le modèle évalué a été entraîné sur un mélange MLSUM + xlsum ? Si oui, comment justifiez-vous de comparer vos scores à ceux publiés sur MLSUM seul, et pourquoi cette information n'apparaît-elle ni dans le résumé ni dans la section résultats ? C'est la question la plus discriminante du mémoire. Un candidat solide reconnaîtra, expliquera la proportion et proposera de re-libeller le protocole. Un candidat fragile découvrira le problème en séance.
Q6. [Incohérence A] La Figure 2.8 annonce « MLSUM (5000 ex.) », le §3.4.2 annonce le corpus complet (TRAIN_SAMPLES=0), et la Figure 3.7 illustre un sous-échantillonnage. Quelle est la configuration exacte du run final dont sont issus les chiffres du Tableau 3.6 ?
Q7. [Incohérence C] Votre système déployé génère avec min_new_tokens=25, mais votre script d'évaluation force min_new_tokens=10. La longueur de génération influence directement le rappel ROUGE. Vos scores mesurent-ils le système que vous livrez ? Quel serait le ROUGE-1 avec la configuration réellement déployée ? Comment répondez-vous à l'objection selon laquelle ce réglage optimise la métrique plutôt que le produit ?
Q8. Vous concluez : « notre modèle dépasse la baseline extractive Lead-3 (20,37 contre 19,69) ». Sur 100 exemples, avec une seule graine, sans intervalle de confiance, et avec une implémentation ROUGE différente (vous n'appliquez pas la racinisation). Cet écart de 0,68 point est-il défendable ? Quel test statistique permettrait de trancher, et pourquoi ne l'avez-vous pas conduit ? Attendu : bootstrap ou test de permutation apparié, écart-type inter-graines, coût d'évaluation sur 15 828 exemples. Le candidat reconnaît la limite en conclusion — vérifier qu'il en comprend la portée réelle.
Q9. Votre comparaison « avant/après réglage fin » oppose un modèle jamais entraîné au résumé à un modèle entraîné au résumé. Ce gain était acquis d'avance. Quelle baseline aurait réellement mis votre travail à l'épreuve ? Vous mentionnez TextRank, LexRank et mT5 en limites : combien de temps vous aurait coûté l'exécution d'un TextRank sur 100 articles ? TextRank prend quelques minutes. La réponse à cette question révèle si l'omission relève d'une contrainte réelle ou d'un manque de rigueur.
Q10. Tableau 3.5 : votre perte d'entraînement remonte à l'époque 3 (2,791 → 2,856) puis à l'époque 5 (2,811 → 2,814), alors que la validation décroît. Vous ne commentez que la validation. Comment expliquez-vous cette non-monotonie ?
Q11. Vous annoncez que « le taux d'hallucinations diminue après réglage fin ». Sur quelle mesure repose cette affirmation ? Combien de résumés ont été annotés, par combien d'annotateurs, avec quel protocole et quel accord inter-annotateurs ? Le Tableau 3.9 ne donne que 3 cas illustratifs. Une affirmation quantitative sans mesure est un défaut de rigueur à faire reconnaître.
Q12. Vous utilisez BERTScore avec lang="fr". Quel modèle sous-jacent est effectivement chargé, et est-il adapté au français journalistique ? Un BERTScore de 0,71 : est-ce bon, moyen ou mauvais ? Par rapport à quelle référence ? Piège utile : BERTScore a un plancher élevé (deux textes français quelconques obtiennent déjà ~0,6-0,65). Le candidat doit savoir qu'un score brut de BERTScore n'est pas interprétable sans rescaling ni baseline.

4.3 Questions génie logiciel et déploiement niveau 2

Q13. [Sécurité] Votre endpoint POST /extract-url télécharge, depuis votre serveur, une URL fournie librement par l'utilisateur. Que se passe-t-il si un utilisateur soumet http://169.254.169.254/latest/meta-data/ ou http://api:8000/ — l'adresse de votre propre conteneur sur le réseau Docker interne ? Comment protégez-vous cet endpoint ? Attendu : reconnaissance de la vulnérabilité SSRF, allowlist de schémas/domaines, blocage des plages IP privées, timeout, taille maximale de réponse.
Q14. Votre API n'a ni authentification ni limitation de débit, alors que chaque appel à /summarize déclenche une inférence GPU de plusieurs secondes. Que se passe-t-il si 200 requêtes arrivent simultanément ? Votre exigence « générer un résumé en moins de 10 secondes » tient-elle sous charge ? Avez-vous mesuré le débit maximal ? Attendu : conscience que FastAPI asynchrone ne parallélise pas l'inférence PyTorch (GIL + GPU sérialisé), nécessité d'une file d'attente ou d'un batching.
Q15. Vous revendiquez la maintenabilité comme exigence non fonctionnelle. Combien de tests unitaires votre projet comporte-t-il ? Comment vérifiez-vous, après une modification du prétraitement, que le pipeline produit toujours des sorties correctes ?
Q16. Dans la Figure 3.1, vous placez « Modèle BARThez » comme acteur du diagramme de cas d'utilisation. Rappelez la définition d'un acteur en UML — et dites-nous si cette modélisation est correcte. Un acteur est une entité externe au système. BARThez est un composant interne. Erreur à faire corriger.
Q17. Votre mécanisme de repli au démarrage sélectionne barthez-finetuned-v2, puis barthez-finetuned, puis barthez (modèle de base). En production, comment un utilisateur sait-il quel modèle a produit son résumé ? Que se passe-t-il si le service démarre silencieusement sur le modèle de base non fine-tuné ? Le champ model_used existe dans la réponse — vérifier qu'il est exposé dans l'interface et non seulement dans le JSON.
Q18. Votre modèle pèse ~530 Mo et le mémoire indique que l'inférence CPU est « adaptée à un usage individuel ». Quel est le temps de génération mesuré sur CPU seul ? Un déploiement sur un serveur sans GPU — configuration la plus probable en Côte d'Ivoire — reste-t-il utilisable ?

4.4 Questions de fond et de positionnement niveau 3

Q19. Votre travail consiste à appliquer une procédure standard (fine-tuning d'un modèle pré-entraîné existant sur un corpus public existant, avec des métriques standard) et à l'encapsuler dans une architecture web classique. Formulez en une phrase la contribution originale de ce mémoire. Qu'apporte-t-il qu'un développeur ne pourrait pas reproduire en suivant un tutoriel Hugging Face ? Question dure mais légitime. Une réponse honnête (« la contribution est d'ingénierie et d'intégration, pas algorithmique ») vaut mieux qu'une surenchère. Écouter si le candidat sait défendre la valeur d'un travail d'ingénierie.
Q20. Vous documentez qu'un article sur une découverte à Angoulême en 2018 produit un résumé mentionnant « présentée mercredi 5 juin à Paris » — date et lieu entièrement inventés. Vous concluez que le système est une « aide à la lecture ». Mais un lecteur pressé qui ne lit que le résumé recevra une information fausse. Un tel système peut-il être responsablement mis en ligne dans son état actuel ? Quel garde-fou minimal exigeriez-vous avant une mise en production réelle ? Attendu : affichage systématique de l'article source, avertissement explicite, surlignage des entités non présentes dans la source, refus de génération sous seuil de confiance.
Q21. Vos références MLSUM sont les chapeaux d'articles du Monde, rédigés par des journalistes pour accrocher le lecteur, pas pour résumer l'article. Le score Oracle plafonne d'ailleurs à 37,69. Votre modèle apprend-il à résumer, ou apprend-il à imiter un style éditorial ? Et si c'est le second cas, votre score ROUGE mesure-t-il ce que vous croyez qu'il mesure ? Question conceptuelle forte. Le candidat aborde la question au §3.7.5 mais sans en tirer toutes les conséquences.
Q22. Le §3.7.4 relève que le modèle fine-tuné réutilise systématiquement « déclare », « indique », « précise ». C'est un appauvrissement lexical. En quoi est-ce problématique pour un outil de synthèse de presse, et quelle stratégie de décodage aurait pu l'atténuer ? Attendu : lien entre beam search + maximisation de vraisemblance et effondrement de la diversité ; alternatives : nucleus sampling, contrastive search, MBR decoding — avec l'arbitrage fidélité/diversité.
Q23. Le résumé de votre exemple 2 (Tableau 3.11) est une quasi-copie de la première phrase de l'article, avec une seule substitution : « actualité » devient « nouvelles ». Est-ce encore un résumé abstractif ? Avez-vous mesuré le taux de copie verbatim (proportion de n-grammes du résumé présents dans la source) ? C'est la métrique standard pour établir l'abstractivité réelle. Métrique d'extractivité/densité de compression (Grusky et al., NEWSROOM). Son absence est une vraie lacune : le mémoire revendique l'abstractivité sans jamais la mesurer.

4.5 Questions prospectives niveau 4 — clôture

Q24. Vous proposez en perspective un « module de vérification factuelle ». Concrètement, comment le construiriez-vous ? Quelles ressources en français existent pour cela ? Attendu : QA-based (QuestEval, QAFactEval), NLI entre résumé et source, extraction et appariement d'entités nommées. Le candidat doit au moins citer une piste opérationnelle.
Q25. Depuis 2023, les grands modèles de langue génèrent des résumés en français de très bonne qualité sans aucun fine-tuning. Quelle est la valeur d'un BARThez à 165 M de paramètres fine-tuné, face à ces modèles ? Attendu : coût, souveraineté et confidentialité des données, absence de dépendance à une API étrangère, latence, déploiement local sans connexion, empreinte énergétique. C'est l'argumentaire décisif — et il n'est pas dans le mémoire, ce qui est dommage.
Q26. Votre perspective la plus intéressante — la constitution d'un corpus journalistique africain francophone — n'occupe que deux lignes. Comment vous y prendriez-vous ? Quelles sources, quel volume minimal, quels obstacles juridiques (droit d'auteur des organes de presse) ?

5. Grille de notation indicative

CritèrePoidsAppréciationJustification
Qualité rédactionnelle et structure15 %BonStructure canonique, prose fluide, figures commentées. Réserve : titre tronqué en couverture, rendu typographique à vérifier.
État de l'art et bibliographie20 %Très bonSources primaires réelles et pertinentes, progression logique RNN → attention → Transformer → modèles pré-entraînés. Réserve : chapitre 1 disproportionné.
Rigueur méthodologique25 %InsuffisantCorpus d'entraînement non conforme à ce qui est annoncé (xlsum), configuration d'évaluation ≠ configuration déployée, n=100, graine unique, aucun IC, aucune baseline exécutée.
Réalisation technique20 %BonChaîne complète fonctionnelle et conteneurisée. Réserve : SSRF, pas d'auth, pas de tests, pas de dépôt public.
Analyse critique des résultats15 %SatisfaisantAnalyse d'erreurs pertinente et honnête, limites reconnues. Mais affirmations quantitatives non étayées et conclusions tirées d'écarts non significatifs.
Originalité de la contribution5 %FaibleApplication standard d'une procédure standard. Apport d'intégration réel, apport scientifique marginal.
Position d'ensemble : mémoire d'ingénierie honnête et bien écrit, dont le point faible est la rigueur du protocole expérimental. Les incohérences B (xlsum) et C (min_new_tokens) sont les deux points sur lesquels la soutenance se jouera : la qualité de la réponse à Q5 et Q7 doit peser lourd dans l'appréciation finale. Le candidat n'a pas cherché à masquer ses limites — c'est un élément favorable à porter à son crédit.

6. Recommandations de correction avant dépôt définitif

  1. Corriger le titre de la page de garde (mot tronqué « pré-entrain », casse de « Transformer »). Vérifier le rendu typographique du PDF final. La ligne « Examinateur » sera renseignée après désignation du jury : rien à corriger.
  2. Rendre le protocole d'entraînement explicite et cohérent : mentionner xlsum dans le résumé, l'abstract et le §3.5, avec la proportion exacte ; harmoniser Fig. 2.8, §3.4.2 et Fig. 3.7.
  3. Réévaluer avec la configuration réellement déployée (min_new_tokens=25) et publier les deux jeux de scores, ou justifier explicitement l'écart.
  4. Étendre l'évaluation à au moins 1 000 exemples, 3 graines, avec écart-type — coût de calcul modeste, gain de crédibilité majeur.
  5. Exécuter au minimum une baseline TextRank et une Lead-3 recalculée avec sa propre chaîne ROUGE, pour rendre le Tableau 3.8 comparable.
  6. Ajouter une mesure d'extractivité (taux de n-grammes copiés) pour étayer la revendication d'abstractivité.
  7. Sécuriser /extract-url (allowlist, blocage des IP privées, timeout, taille max) et ajouter au moins une limitation de débit.
  8. Publier le dépôt de code avec le commit exact et le requirements.txt figé, ou joindre les scripts en annexe.
  9. Déplacer le Tableau 3.1 (14 diagrammes UML) en annexe et alléger le chapitre 1.
  10. Corriger la Figure 3.1 : retirer « Modèle BARThez » des acteurs.