Hackathon LLM agents & MCP à Lyon 1 (18-20/11) : venir avec un cas, repartir avec un RAG fiable

Pourquoi ce hackathon vaut ton temps (si tu viens préparé)

Trois jours, sur le campus de l’Université Claude Bernard Lyon 1 à La Doua (Villeurbanne), du 18 au 20 novembre 2026. Thème clair : agents LLM et MCP (Model Context Protocol), avec un ancrage assumé sciences de la vie, bioinfo, santé. L’événement est organisé par IFB/ELIXIR-FR, dans le cadre de son axe stratégique IA et du projet Mudis4LS, et hébergé par PRABI-AMSB sur le campus de La Doua. Source : IFB/ELIXIR-FR et présentation PRABI-AMSB.

Le piège classique des hackathons GenAI, c’est de partir sur un assistant “généraliste” et de repartir avec une démo qui hallucine, impossible à défendre devant un métier ou un DPO. Ici, l’objectif réaliste, c’est de repartir avec un prototype RAG traçable et un agent qui enchaîne des actions utiles, avec des garde-fous minimum.

Si tu veux une phrase simple : viens avec un problème borné, un corpus propre et une définition de “réponse correcte”. Tu repars avec quelque chose de testable.

Les infos vérifiées (hackathon IA Lyon 1, La Doua)

• Dates : 18 au 20 novembre 2026
• Lieu : Université Claude Bernard Lyon 1, campus de La Doua (Villeurbanne)
• Hébergement : PRABI-AMSB
• Organisateurs : IFB/ELIXIR-FR (axe IA) dans le cadre du projet Mudis4LS
• Thème : agents LLM et MCP (Model Context Protocol), cas d’usage orientés sciences de la vie

PRABI-AMSB est une plateforme de bioinformatique située à La Doua, affiliée à Lyon 1 et à la fédération BioEEnvis, avec un historique de collaborations autour du numérique, du cloud académique, de l’IA et du HPC en sciences de la vie. Source : page de présentation PRABI-AMSB (BioEEnvis).

À qui ça s’adresse (et à qui ça ne sert à rien)

Ce hackathon est naturellement taillé pour les cas où la qualité et la traçabilité comptent plus que l’effet waouh.

Profils qui vont en tirer quelque chose

• Bio, santé, sciences de la vie : biologie, bioinfo, cliniciens, qualité, data stewardship.
• Ingénierie : dev backend, data engineers, ML engineers, MLOps, architectes.
• Recherche : chercheurs et doctorants qui veulent prototyper vite sans sacrifier la rigueur.
• Conformité : RSSI, DPO, ou au minimum une personne qui sait dire “stop, là on sort du cadre”.

Équipe type qui marche en 72 h

• 1 personne métier (celle qui connaît les questions récurrentes et ce qui est “juste”)
• 1 personne tech (celle qui code, déploie, branche les sources)
• 1 personne sécurité/RGPD (ou référent conformité) pour éviter de construire un prototype inutilisable

Erreur fréquente : venir “solo dev” sans expertise métier. Tu vas optimiser des prompts au lieu de résoudre un vrai problème.

LLM agents, RAG, MCP : version utile, sans blabla

RAG (Retrieval-Augmented Generation)

Le RAG, c’est : je cherche dans un corpus, puis je réponds à partir des passages retrouvés. Tu gagnes deux choses : moins d’hallucinations, et surtout des citations pour justifier la réponse. Pour un usage santé ou qualité, c’est non négociable.

Objectif hackathon : un RAG qui sait dire “je ne sais pas” quand la réponse n’est pas dans le corpus, au lieu d’inventer.

Agents LLM

Un agent, ce n’est pas un chat qui bavarde. C’est un LLM qui enchaîne des actions : formuler une requête, interroger un moteur de recherche interne, filtrer, vérifier, produire une sortie structurée, puis se relire.

Au hackathon, vise un agent “orchestrateur” simple. Exemple : reformule la question, retrouve les sources, répond avec citations, vérifie qu’il y a bien une source, sinon “je ne sais pas”.

MCP (Model Context Protocol)

MCP est un standard promu par Anthropic pour connecter un assistant à des outils et des sources de données via des serveurs MCP. L’intérêt : arrêter le bricolage de connecteurs ad hoc, et brancher des capacités de manière plus standardisée. Le protocole évolue, et une spécification MCP 2026-07-28 est présentée comme une 5e release. Source : blog Claude (Anthropic).

Traduction hackathon : MCP peut te faire gagner du temps pour brancher proprement des ressources (documents, bases, services) à ton agent. Mais seulement si tu arrives avec un cas d’usage borné.

Choisir un cas d’usage réaliste (celui qui te fait gagner le hackathon)

Le bon cas d’usage tient dans une phrase, et se teste en questions-réponses.

Format recommandé

“Répondre à X questions récurrentes en citant précisément les passages sources, sur un corpus Y, dans un cadre Z.”

Exemples qui collent bien à l’ancrage bio/santé :

• RAG santé sur procédures de prélèvement, critères d’inclusion/exclusion, règles d’étiquetage, checklists qualité.
• Assistant SOP : “Quelle étape change selon le type d’échantillon ?” avec citation de la version à jour.
• Questions de conformité interne : “Quelle est la durée de conservation recommandée pour tel type de donnée ?” sur documentation qualité.
• RAG sur corpus de publications biomédicales ciblées, avec réponses qui citent titres, auteurs, et extraits.

Ce qu’il faut éviter (même si ça fait envie)

• “Un assistant pour tout le service”. Trop large, impossible à évaluer en 3 jours.
• “On va fine-tuner un modèle”. Tu vas cramer le temps en infra et dataset.
• “On met des données patients et on voit”. Non. Tu vas te bloquer RGPD et sécurité.

Pré requis techniques (minimum viable, pas la stack parfaite)

Ton but n’est pas d’installer la cathédrale. Ton but est de livrer un prototype testable.

Ce qu’il te faut avant d’arriver

• Un repo prêt (même vide) avec un README “how to run”.
• Un pipeline d’ingestion basique : charger docs, découper, indexer.
• Un pipeline de requête : retrieval, génération, citations, réponse structurée.
• Une UI simple : web minimal ou CLI. Peu importe, tant que c’est testable.
• Un plan B si le réseau ou l’accès à des API bloque : dataset local et exécution dégradée.

Compétences utiles dans l’équipe

• Manipulation de PDF, HTML, exports Confluence, nettoyage OCR.
• Notions d’indexation, embeddings, recherche hybride (lexicale + sémantique).
• Notions de sécurité applicative (secrets, logs, accès).
• Notions RGPD, surtout si tu touches à des données liées à la santé.

Checklist données : venir avec un corpus qui ne te sabote pas

Le RAG, c’est 80 % de données, 20 % de modèle. Si tes documents sont pourris, tout est pourri.

Le mini-corpus “hackathon-ready”

• 20 à 200 documents maximum, stables, à jour. Pas 10 000 PDFs tombés d’un SharePoint.
• Versionnés : tu sais quelle version est la “source de vérité”.
• Textes extractibles : éviter les PDFs scannés illisibles (sinon tu perds une journée en OCR).
• Structure : titres, sections, tableaux identifiés si possible.
• Droits : tu as le droit d’utiliser ces docs pendant le hackathon.

RGPD et santé : règle simple

En santé, tu pars du principe que c’est sensible jusqu’à preuve du contraire. La CNIL rappelle une définition large des données de santé au sens RGPD. Source : CNIL (définition des données de santé).

Anonymisation vs pseudonymisation : point que tout le monde rate

La CNIL rappelle que la pseudonymisation est une mesure recommandée, mais ne sort pas automatiquement du RGPD, contrairement à une anonymisation robuste. Source : CNIL (anonymisation).

Donc, pour un hackathon, vise un corpus sans données directement identifiantes et, si possible, sans données patients du tout. Le plus efficace : travailler sur de la documentation, des SOP, de la littérature, des référentiels.

À préparer dans un fichier texte avant de venir

• Origine des documents (où, qui, quand).
• Droit d’usage (interne, licence, autorisation).
• Durée de conservation envisagée du corpus “hackathon”.
• Qui est habilité à accéder aux docs.
• Ce qui est explicitement interdit (ex : données nominatives, identifiants).

Si tu hésites entre anonymisation et pseudonymisation, la CNIL recommande d’impliquer le DPO en cas d’incertitude. Source : guide CNIL (SPST, recommandation d’implication du DPO en cas de doute).

Critères de succès : décide avant d’indexer, pas après

Sans critères, tu ne sais pas si ton prototype est bon, juste s’il “a l’air” bon.

Critères simples, mesurables

• Traçabilité : 90 % des réponses affichent au moins une citation vérifiable (doc, section, extrait).
• Refus : quand la réponse n’est pas dans le corpus, l’agent répond “je ne sais pas” au lieu d’inventer.
• Pas de réponse sans source quand la sensibilité est haute (santé, qualité).
• Temps de réponse : inférieur à X secondes sur un corpus de taille Y.

Jeu de test minimal (à faire la veille)

• 20 questions réelles, posées comme les utilisateurs les posent.
• Pour chaque question : une “réponse attendue” ou au minimum le passage source exact.
• 5 questions pièges : la réponse n’est pas dans le corpus (ton test de non-hallucination).

Si tu veux une méthode carrée pour structurer ce jeu de tests, tu peux t’appuyer sur notre guide interne : Comment évaluer la réponse d'une IA : construire son jeu de tests.

Garde fous : sécurité, conformité, et fiabilité (sinon ton agent fait n’importe quoi)

Sécurité : commence petit, verrouille vite

• Secrets : jamais en dur dans le repo. Variables d’environnement, coffre si dispo.
• Logs : pas de contenu sensible dans les logs. Journalise les IDs de docs, pas les extraits complets.
• Accès : principe du moindre privilège pour les connecteurs et outils.
• Prompt injection : considère que tes documents peuvent contenir des instructions malveillantes.

Pour poser des garde-fous agentiques concrets, tu peux t’appuyer sur : Agents IA : 10 garde-fous avant d’automatiser en entreprise (accès, données, actions) et Injection de prompt : la faille que les entreprises sous-estiment.

Évaluation : ton RAG doit passer 4 checks

Un cadre courant d’évaluation RAG consiste à mesurer : (1) la qualité du retrieval, (2) la groundedness, (3) la faithfulness, (4) la pertinence end-to-end. Source : Openlayer (cadre d’évaluation RAG).

Version hackathon :

• Retrieval : est-ce que les bons passages sortent dans le top k ?
• Ancrage : est-ce que la réponse s’appuie bien sur ces passages ?
• Fidélité : est-ce qu’il déforme le passage ?
• Utilité : est-ce que ça répond à la question utilisateur, dans le format attendu ?

RGPD : pas de flou artistique

Tu veux un rappel clair, côté entreprise : RGPD et IA en entreprise : ce que vous pouvez faire, ce que vous ne pouvez pas. Et si ton sujet touche à l’exposition de données via outils GenAI, lis aussi : Shadow AI en entreprise : détecter et cadrer les usages IA non autorisés.

Résultats attendus : ce que tu dois viser à J3

Si tu veux repartir avec du concret, vise trois livrables. Pas un seul.

1) Un prototype RAG fiable

• Un corpus ingéré proprement
• Une recherche qui retrouve les bons passages
• Une réponse avec citations et un mode je ne sais pas
• Un log minimal des requêtes (sans données sensibles)

2) Un backlog priorisé (ce qui manque pour passer du prototype au pilote)

• Qualité données : OCR, normalisation, versioning
• Sécurité : gestion secrets, contrôle d’accès, audit
• Évaluation : dataset plus large, métriques, tests de non-régression
• Produit : UI, workflow, intégration outil métier

3) Des next steps datés

• Qui est propriétaire du sujet (métier et tech)
• Où vit le corpus (et qui a le droit d’y toucher)
• Comment on valide (jeu de tests, seuils, revue conformité)
• Quand on re-teste (J+15, J+30)

Plan de préparation en 7 jours (simple, efficace)

• J-7 : choisir 1 cas d’usage, écrire la phrase “problème, corpus, cadre”.
• J-6 : sortir un mini-corpus propre, éliminer les PDFs scannés illisibles.
• J-5 : écrire 20 questions réelles + 5 questions sans réponse dans le corpus.
• J-4 : définir 3 critères de succès chiffrés.
• J-3 : décider sécurité et RGPD (ce qui est autorisé, interdit, loggable).
• J-2 : préparer repo + script ingestion + script éval basique.
• J-1 : dry run de bout en bout sur ton laptop. Tu corriges tout ce qui casse.

Ce que tu gagnes à le faire à Lyon 1, pas seul dans ton coin

Le bon point d’un hackathon ancré Université Lyon La Doua IA, avec un hébergement PRABI-AMSB et un cadrage IFB/ELIXIR-FR, c’est l’environnement. Tu peux confronter ton idée à des gens qui vivent les contraintes sciences de la vie, qualité, données sensibles. Tu corriges tôt. Tu gagnes du temps.

Et si ton sujet dérive vers “agent qui fait tout”, tu vas te faire recadrer. Tant mieux.

Action : viens avec ces 5 éléments, repars avec un prototype défendable

Checklist finale, à copier-coller :

• 1 cas d’usage borné en format Q/R vérifiable.
• Un corpus propre (20 à 200 docs), versionné, avec droits d’usage clairs.
• Un jeu de test (20 questions réelles + 5 “hors corpus”).
• Des critères de succès (citations, refus, temps, zéro réponse sans source).
• Un cadre RGPD écrit noir sur blanc (ce qui est autorisé, interdit, loggable).

Si tu fais ça, tu n’es plus dans la démo. Tu es dans un prototype RAG santé testable et améliorable. C’est exactement ce que ce hackathon IA Lyon 1 peut te permettre de sortir en trois jours.