← Dossier de décision · Fiches de lecture · 14 juillet 2026

Les 9 références du mini-projet — fiches de lecture

Objectif : pouvoir soutenir 20 minutes de conversation avec un encadrant sur chacune de ces références. Chaque fiche donne l'essentiel, les limites (c'est souvent là-dessus qu'on te testera), le lien avec tes contributions C1/C2/C3, et la phrase à savoir dire.

Ordre de lecture conseillé (~12-15 h sur 7-10 jours)
  1. Vidgof (nº 1, 1 h) puis ProAgent (nº 2, 1 h 30) — le cadre BPM × LLM : le langage de Baïna.
  2. MAST (nº 3, 2 h) — le cœur de ta contribution fiabilité.
  3. TAWOS (nº 4, 1 h) puis Deep-SE (nº 5, 1 h 30) puis GPT2SP (nº 6, 1 h 30) — tes données et tes baselines.
  4. Teinemaa (nº 7, 2 h, lecture partielle) et van der Aalst ch. 1-2 (nº 8, 2-3 h) — le socle process mining.
  5. OWASP (nº 9, 30 min) — survol.

1. Large Language Models for Business Process Management: Opportunities and Challenges cadre général

Vidgof M., Bachhofner S., Mendling J. — BPM Forum 2023

📄 arxiv.org/abs/2304.04309

Ce que dit l'article
Papier de positionnement (court, facile) : les auteurs — dont Jan Mendling, figure majeure du BPM — passent en revue le cycle de vie BPM (identification, découverte, analyse, redesign, implémentation, monitoring) et cartographient où les LLM peuvent intervenir, en dégageant six directions de recherche et les défis associés (hallucination, coût, intégration aux systèmes, gouvernance).
Limites
C'est un agenda, pas une contribution technique : aucune expérimentation. Écrit en 2023, avant l'ère des agents — il parle de LLM « assistants », pas d'agents autonomes.
Lien avec ta thèse
C'est le pont entre ton sujet et la communauté de Baïna : ta thèse s'attaque précisément aux étapes implémentation/monitoring que ce papier laisse ouvertes, avec la dimension agentique qu'il n'anticipait pas encore.
À savoir dire : « Vidgof et Mendling ont posé l'agenda LLM × BPM en 2023 ; ma thèse prend la suite sur la partie exécution et supervision, avec des agents autonomes — ce que le papier n'envisageait pas encore. »

2. ProAgent: From Robotic Process Automation to Agentic Process Automation concept fondateur

Ye Y., Cong X., Tian S. et al. (Tsinghua NLP) — arXiv, 2023

📄 arxiv.org/abs/2311.10751

Ce que dit l'article
Le papier qui a inventé le terme Agentic Process Automation (APA). ProAgent reçoit une instruction en langage naturel, génère un workflow exécutable (dans un langage de description dédié), puis l'exécute avec deux agents spécialisés : un DataAgent pour les décisions sur données et un ControlAgent pour les branchements dynamiques. Là où le RPA rejoue des clics figés, l'APA délègue à l'agent la construction et les décisions du workflow.
Limites
Validation par études de cas démonstratives uniquement — pas d'évaluation systématique, pas de processus réels longitudinaux, et la fiabilité n'est pas traitée. Exactement le fossé que ta thèse vise.
Lien avec ta thèse
Fonde le concept central du sujet. Ses manques justifient C1 (évaluer sérieusement) et C3 (fiabiliser) ; son cadre workflow inspire l'architecture de C2.
À savoir dire : « ProAgent a montré la faisabilité de l'APA sur des démos ; personne n'a encore évalué ces agents sur des processus réels avec des années d'historique — c'est ma contribution C1. »

3. Why Do Multi-Agent LLM Systems Fail? (taxonomie MAST) cœur de C3

Cemri M., Pan M.Z., Yang S. et al. (UC Berkeley) — 2025

📄 arxiv.org/abs/2503.13657

Ce que dit l'article
Première taxonomie empirique des échecs de systèmes multi-agents LLM : plus de 1 600 traces d'exécution annotées, issues de 7 frameworks populaires, aboutissant à 14 modes d'échec regroupés en 3 catégories : (i) défauts de spécification et de conception du système, (ii) désalignement inter-agents, (iii) vérification et terminaison des tâches. Le pipeline d'annotation utilise un LLM-juge validé par accord inter-annotateurs, et les interventions simples testées (meilleurs prompts, orchestration) n'apportent que des gains limités — les échecs sont structurels.
Limites
Corpus centré sur des benchmarks académiques (programmation, math…) : aucune trace de processus métier, où une erreur a un coût organisationnel et où le workflow a une structure normée (SCRUM) exploitable.
Lien avec ta thèse
C'est la colonne vertébrale de C3 : étendre MAST aux processus d'entreprise, puis passer du diagnostic a posteriori à la détection prédictive en cours d'exécution, avec le conformance checking comme garde-fou — ce que leur corpus ne permet pas.
À savoir dire : « MAST classe les échecs en trois familles — conception, coordination inter-agents, vérification — mais sur des benchmarks académiques ; je propose de l'étendre aux processus métier où l'on dispose d'un référentiel de conformité pour détecter et confiner ces échecs. »

4. A Versatile Dataset of Agile Open Source Software Projects (TAWOS) socle de C1

Tawosi V., Al-Subaihin A., Moussa R., Sarro F. (UCL) — MSR 2022 · DOI 10.1145/3524842.3528029

📄 arxiv.org/abs/2202.00979 · 💾 github.com/SOLAR-group/TAWOS

Ce que dit l'article
Dataset public de tickets JIRA de projets agiles open source (Apache, MongoDB, Atlassian, Moodle, Hyperledger…), livré en base relationnelle avec champs bruts et dérivés : story points, sprints, transitions d'états horodatées, commentaires, liens entre tickets. Conçu « versatile » : estimation d'effort, priorisation, affectation, analyse de processus. ⚠️ Chiffres à citer prudemment : le papier annonce ~500 000 tickets / 44 projets ; le dépôt GitHub actuel documente 458 232 tickets / 39 projets / 12 dépôts Jira — dis « environ un demi-million de tickets » et précise la version si on te pousse.
Limites
Open source uniquement : équipes distribuées, bénévoles, rituels SCRUM hétérogènes — pas représentatif des organisations. C'est ton meilleur argument pour la valeur des terrains industriels conventionnés.
Lien avec ta thèse
Base publique de C1 (reproductibilité) et matière première des event logs pour RQ2. À terme, ton benchmark = tâches TAWOS + tâches sur données industrielles anonymisées.
À savoir dire : « TAWOS me donne la reproductibilité ; mais il est 100 % open source — la validation sur des processus d'organisations réelles est exactement ce qui manque à la littérature, et ce que j'apporte. »

5. A Deep Learning Model for Estimating Story Points (Deep-SE) baseline historique

Choetkiertikul M., Dam H.K., Tran T., Pham T., Ghose A., Menzies T. — IEEE TSE, 2019

📄 arxiv.org/abs/1609.00489

Ce que dit l'article
Premier modèle d'apprentissage profond de bout en bout pour estimer les story points : un LSTM encode le titre + la description du ticket, un Recurrent Highway Network fait la régression — aucune ingénierie de features manuelle. Introduit un dataset de 23 313 tickets issus de 16 projets open source, et bat les baselines (moyenne, médiane, TF-IDF + régresseurs classiques) en erreur moyenne absolue et en accuracy standardisée.
Limites
La généralisation inter-projets est faible — les story points sont une convention locale à chaque équipe, pas une unité absolue. Le texte du ticket est la seule entrée : tout le contexte processus (flux, historique d'équipe, sprint) est ignoré.
Lien avec ta thèse
Baseline obligatoire de C2. Sa cécité au processus est précisément ce que RQ2 attaque : est-ce que les features de process mining comblent ce que le texte seul ne voit pas ?
À savoir dire : « Deep-SE a ouvert la voie en 2019, mais il n'estime qu'à partir du texte du ticket ; mon hypothèse RQ2 est que le contexte processus — que le process mining extrait — porte une information complémentaire mesurable. »

6. GPT2SP: A Transformer-Based Agile Story Point Estimation Approach baseline moderne

Fu M., Tantithamthavorn C. (Monash) — IEEE TSE, 2023 · DOI 10.1109/TSE.2022.3158252

📄 doi.org/10.1109/TSE.2022.3158252 · 💾 github.com/awsm-research/gpt2sp

Ce que dit l'article
Successeur de Deep-SE fondé sur un Transformer (GPT-2 fine-tuné) : meilleure gestion du vocabulaire (sub-words au lieu de mots inconnus) et de la transférabilité. Évalué sur les 16 projets de Deep-SE dans trois scénarios — intra-projet, intra-dépôt, inter-dépôts — où il surpasse Deep-SE. Apporte aussi un volet explicabilité (visualisation de l'attention, évaluée auprès de praticiens) et une démo web utilisable.
Limites
Toujours mono-tâche et aveugle au processus ; modèle pré-LLM (GPT-2) — la comparaison avec des agents LLM modernes reste à faire, et c'est ouvert.
Lien avec ta thèse
Baseline état de l'art de C2, et son souci d'explicabilité pour les praticiens rejoint ta supervision human-in-the-loop de C3 (argument qui parlera aussi à Berrado, si tu le contactes).
À savoir dire : « GPT2SP a montré qu'un Transformer bat Deep-SE et que l'explicabilité compte pour l'adoption ; personne n'a encore mesuré ce qu'apportent les agents LLM contemporains sur ces mêmes tâches — c'est une des premières expériences de mon année 2. »

7. Outcome-Oriented Predictive Process Monitoring: Review and Benchmark méthodo process mining

Teinemaa I., Dumas M., La Rosa M., Maggi F.M. — ACM TKDD, 2019

📄 arxiv.org/abs/1707.06766

Ce que dit l'article
Revue systématique + benchmark du monitoring prédictif « orienté résultat » : prédire, pour un cas de processus en cours, son issue (réclamation, retard, rejet…). Taxonomie croisant le bucketing des préfixes (unique, par longueur, par clustering, par état) et l'encodage des séquences (dernier état, agrégation, index-based), évaluée avec 11 méthodes sur 24 tâches issues de 9 event logs réels, avec protocole et métriques standardisés. Enseignement robuste : les encodages par agrégation + gradient boosting sont les plus fiables en pratique.
Limites
Antérieur aux LLM ; logs de processus administratifs (banque, hôpital), pas de développement logiciel. Lecture partielle suffisante : taxonomie (§3-4) + résultats (§6).
Lien avec ta thèse
Deux usages : la boîte à outils des features processus injectées dans tes agents (RQ2), et le modèle de rigueur expérimentale — protocole, métriques, anti-fuite temporelle — pour construire le benchmark C1.
À savoir dire : « Teinemaa fournit la grille encodage × bucketing du monitoring prédictif ; je transpose cette grille aux event logs JIRA pour nourrir les agents en contexte processus, et je reprends leur rigueur de protocole pour mon benchmark. »

8. Process Mining: Data Science in Action socle conceptuel

van der Aalst W. — Springer, 2ᵉ éd., 2016 (livre de référence du domaine)

📄 link.springer.com/book/10.1007/978-3-662-49851-4

Ce que dit le livre
LA référence fondatrice, par le père du process mining. Trois piliers : la découverte (inférer un modèle de processus depuis un event log — algorithme alpha, inductive miner), le conformance checking (mesurer l'écart entre comportement observé et modèle prescrit, par token replay ou alignements), et l'enhancement (enrichir le modèle avec les données réelles). Définit le format standard des event logs (cas, activité, horodatage — XES) — exactement la structure des transitions JIRA.
Comment le lire
Ne pas tout lire : chapitres 1-2 (concepts, event logs) en entier, puis survoler la découverte et lire attentivement la partie conformance checking. L'outillage pratique est aujourd'hui pm4py (Python).
Lien avec ta thèse
Le vocabulaire de la communauté de Baïna — indispensable en entretien. Le conformance checking est le mécanisme technique de ton garde-fou RQ3 : un agent dont les actions dévient du modèle de processus est détecté et confiné.
À savoir dire : « Je reprends le conformance checking de van der Aalst mais en inversant l'usage : au lieu d'auditer des humains a posteriori, il devient un garde-fou temps réel pour des agents IA. »

9. OWASP Top 10 for Large Language Model Applications cadrage sécurité

OWASP GenAI Security Project — édition 2025

📄 genai.owasp.org/llm-top-10

Ce que dit le document
Classement de référence des risques des applications LLM. À retenir : LLM01 — l'injection de prompt reste le risque nº 1, sans solution générale (un ticket JIRA malveillant pourrait manipuler ton agent de triage !), et les risques agentiques montent — excessive agency (agent doté de trop de droits), insecure output handling, empoisonnement des données. Survol de 30 minutes.
Lien avec ta thèse
Justifie que C3 ne soit pas un luxe : un agent branché sur le JIRA d'une organisation lit du contenu non fiable (tickets externes, commentaires) — le confinement par conformance checking répond à l'excessive agency.
À savoir dire : « Le contenu d'un ticket est une entrée non fiable : un agent de backlog est exposé à l'injection de prompt par construction — d'où mes garde-fous au niveau du processus plutôt qu'au niveau du modèle. »