Hackathon IA Lyon 1 (18/11) agents LLM et MCP : viens avec un cas bio-santé hackable en 48 h

Tu veux venir avec un cas bio-santé. Pas une démo gadget.

Un hackathon, c’est court. Très court. En bio-santé, c’est encore plus piégeux: données sensibles, formats pénibles, jargon partout, et une “démo waouh” qui s’écroule dès qu’on pose une question précise.

Le bon move: arriver avec un cas d’usage cadré, un petit set de données prêt, et un livrable rejouable. Tu sors de là avec un prototype utile, pas un chatbot qui raconte n’importe quoi.

Cet article te donne une méthode simple pour préparer ton sujet “biologie-santé” exploitable en 48 h, avec un focus concret sur ce que MCP change quand tu construis des agents LLM.

Le cadre officiel de l’événement (à connaître, point)

Nom: Hackathon IA « Agent LLM et MCP ». Source: ifb-elixir.fr

Dates et format: du mercredi 18 novembre 2026 (14h00) au vendredi 20 novembre 2026 (12h00), sur 4 demi-journées (intro, sessions de hacking, restitution). Source: ifb-elixir.fr

Lieu: Université Claude Bernard Lyon 1, campus La Doua (Villeurbanne), hébergé par PRABI-AMSB. Source: ifb-elixir.fr

Cadre: organisé par IFB/ELIXIR-FR dans le cadre de son axe stratégique IA et du projet Mudis4LS. Source: ifb-elixir.fr

Public visé côté organisateur: chercheurs et ingénieurs IFB/ELIXIR-FR intéressés par l’IA appliquée à la biologie. Source: ifb-elixir.fr

Technos et sujets annoncés: RAG, agents, MCP, usage via API ALBERT (DINUM), Ollama, création d’un MCP basique avec FastMCP, et « tool calling et agents via le package OpenAI ». Source: ifb-elixir.fr

Pré-inscription: indiquée comme obligatoire sur la page IFB/ELIXIR-FR. Source: ifb-elixir.fr

À qui ça s’adresse, si tu viens avec un cas biologie-santé

Sur le papier, c’est orienté chercheurs et ingénieurs IFB/ELIXIR-FR. Dans les faits, si tu veux contribuer utilement, il te faut un cas qui colle à trois contraintes:

• Hackable en 48 h: pas de “on va refaire une pipeline clinique complète”.
• Évaluable: tu peux dire si ça marche, vite, sur des exemples “gold”.
• Présentable: une démo + un mini rapport, pas un notebook illisible.

Typiquement, un sujet d’IA bioinformatique à Lyon qui marche bien en hackathon, c’est un outil de lecture, de tri, de structuration et de vérification de connaissances à partir de sources publiques (ou synthétiques) avec des sorties structurées et des citations.

Ton équipe: les profils qui comptent vraiment en 48 h

Tu peux venir seul. Tu peux aussi perdre 12 heures à te battre avec la data et l’intégration. Le hackathon “agents LLM et MCP” pousse implicitement vers des prototypes concrets. Donc vise une mini équipe qui couvre ces fonctions.

1) Domain expert bio-santé (indispensable)

Biologiste, bioinformaticien, clinicien, data manager. Son rôle: cadrer le besoin, dire ce qui est scientifiquement acceptable, et poser les limites (réglementaire, éthique, interprétation).

2) Ingé LLM / agent (indispensable)

RAG, tool calling, prompts, orchestration, garde-fous. Son rôle: faire un agent qui bosse, pas un chatbot qui “discute”.

3) Data engineer ou ML engineer (très utile)

Nettoyage, formats, pipeline simple, évaluation. Son rôle: te sortir du marécage des données, et te donner une boucle d’itération rapide.

4) Dev intégration outillage (très utile)

API, Docker, logs, reproductibilité, packaging de démo. Son rôle: rendre le truc montrable et rejouable. Sans ça, tu présentes un écran de terminal qui plante.

5) Optionnel mais précieux: sécurité / conformité

Si tu touches des données sensibles, même pseudonymisées. En hackathon, la meilleure stratégie c’est souvent: ne pas toucher de données patient. Mais si tu dois, viens avec un plan clair.

Le cadrage “1 phrase” pour ne pas te disperser

Si tu n’as pas une phrase actionnable, tu n’as pas un cas. Tu as une idée floue.

Utilise ce modèle:

“À partir de [source], produire [sortie] pour aider [utilisateur] à [décision/action], avec [contrainte de temps/qualité].”

Exemples bio-santé (sans données patient)

• “À partir d’articles PubMed + guidelines publiques, produire un résumé sourcé et un tableau des critères d’inclusion/exclusion pour un essai, en moins de 2 minutes par sujet.”
• “À partir de fiches UniProt + ontologies, extraire des relations gène-protéine-pathway en JSON, avec une citation par assertion.”
• “À partir de comptes rendus de protocoles publics, générer une check-list de conformité et détecter les champs manquants.”

Tu remarques le point commun: sortie structurée + sources + contrainte. Parfait pour un agent IA santé qui doit être vérifiable.

Objectifs et métriques: choisis du mesurable, pas du “ça a l’air bien”

Le piège: passer 30 heures sur une UI et 0 heure sur la qualité. Ton objectif doit survivre à une démo où on te challenge.

Choisis 1 à 3 métriques simples

• Exactitude factuelle: % de réponses correctement sourcées sur un jeu de questions.
• Couverture: % de champs structurés remplis correctement (ex: critères, gènes, interactions, unités).
• Robustesse: comportement attendu quand la source manque (refus, demande d’info, pas d’hallucination).

Tu peux préparer une éval minimaliste: 20 questions, 20 “gold answers” même partielles, et un scoring simple. Si tu veux aller plus loin, garde ça lisible et reproductible.

Pour la méthode de cadrage générale, tu peux aussi t’appuyer sur ce guide Lyon IA (utile même en hackathon): https://lyon-ia.com/blog/cadrer-un-projet-ia-methode

Données: vise petit, propre, partageable

En 48 h, la donnée “parfaite” n’existe pas. Tu veux de la donnée prête à hacker.

Dataset minimal recommandé

• Public si possible (PubMed, UniProt, ontologies, jeux open).
• Ou synthétique.
• Ou dé-identifié et clairement autorisé.

Format: CSV/JSON simple. Quelques dizaines à quelques centaines d’items. Plus 5 à 20 documents de référence “canon”.

Évite: dumps bruts, PDF non OCR, fichiers énormes, formats exotiques sans parseur prêt.

Ton “gold set”: la clé pour avancer vite

Prépare 20 à 50 cas avec une sortie attendue. Même imparfaite. Même “incomplète mais correcte”. Sans ça, tu ne sais pas si tu progresses, tu changes juste de prompts.

Livrable: décide dès le début ce que tu vas montrer

Un hackathon, ça se gagne (ou se réussit) avec un livrable simple et solide:

• Une pipeline rejouable (script, makefile, ou workflow clair).
• Une démo (CLI propre ou petite UI).
• Un README qui explique comment lancer, avec prérequis.
• Une mini évaluation (jeu de test + métriques).

Si tu veux faire “agent + RAG + MCP + UI + fine-tuning + dashboard”, tu vas finir avec rien.

Mini check-list: data prête, risques, livrable

Data prête

• ☐ Données autorisées (licence, consentement, usage interne) et partageables avec l’équipe sur place
• ☐ Exemples “gold”: 20 à 50 cas avec réponses attendues (même partielles)
• ☐ Dictionnaire de données: champs, unités, valeurs manquantes
• ☐ Jeu de tests “mini” (10 cas) + jeu “démo” (30 à 100 cas)

Risques

• ☐ Données sensibles: plan B public/synthétique si doute
• ☐ Dépendances externes: fallback local (modèle local via Ollama est cité par l’organisateur)
• ☐ “Agent qui invente”: refus explicite, citations obligatoires, et réponse “je ne sais pas” autorisée

Livrable

• ☐ Une commande unique pour lancer la démo (ou un script)
• ☐ Logs lisibles + traces des appels outils
• ☐ Une page de résultats: métriques + exemples bons/mauvais
• ☐ Une slide unique “ce qui marche / ce qui ne marche pas / next step”

Focus MCP: ce que ça change vraiment pour des agents LLM en bio-santé

MCP (Model Context Protocol), c’est l’idée d’un standard pour brancher un LLM à des outils et des sources via des connecteurs, avec une logique de permissions. En hackathon, ça t’aide à ne pas coder des intégrations jetables à la main.

Si tu veux le topo simple avant de venir: https://lyon-ia.com/blog/mcp-protocole-explique

1) Connecteurs: tu industrialises l’accès aux sources

En bio-santé, ton agent doit souvent naviguer entre plusieurs mondes:

• des documents (guidelines, SOP, publications)
• des bases (gènes, protéines, variants, pathways)
• des fichiers locaux (CSV, JSON, FASTA simplifié, exports)

Avec MCP, tu peux exposer ces accès comme des “tools” standardisés. Résultat: l’agent n’est plus un prompt qui “imagine” une recherche, il exécute une action outillée.

2) Tools: tu forces l’agent à produire du vérifiable

Un bon pattern hackathon:

• Tool “search” (retrouver les sources)
• Tool “extract” (extraire en schéma JSON)
• Tool “validate” (contrôler unités, champs, cohérence)
• Tool “cite” (lier chaque assertion à une source)

En bio-santé, ça te protège contre le syndrome “l’agent raconte une vérité alternative”. Tu peux aussi loguer précisément quelles sources ont été utilisées.

3) Permissions: tu limites la casse (et tu dors mieux)

Agentique + bio-santé = attention. Même si tu n’as pas de données patient, tu peux faire des bêtises: accéder à une ressource non prévue, exfiltrer un fichier, appeler une API payante en boucle.

MCP pousse une logique où tu définis ce que l’agent a le droit de faire. En hackathon, vise simple:

• Lecture seule sur les docs et datasets
• Écriture uniquement dans un dossier “output”
• Pas d’accès réseau libre si tu peux l’éviter

Pour les garde-fous “agents + accès aux outils”, ce guide Lyon IA est utile: https://lyon-ia.com/blog/securiser-un-agent-ia

4) Bio-santé: MCP t’aide à découper en micro-actions propres

Le meilleur usage de MCP en hackathon, ce n’est pas “regarde, j’ai MCP”. C’est “j’ai un agent qui enchaîne des étapes propres et contrôlées”:

• ingestion d’un corpus
• RAG sur sources ciblées
• extraction structurée
• contrôles qualité
• rapport final sourcé

Ça, c’est une démo qui tient. Même si l’UI est moche.

Plan de bataille sur 4 demi-journées (réaliste)

Demi-journée 1: cadrage dur + data

• Problème en 1 phrase, validé par le domain expert
• Choix des métriques
• Dataset minimal + gold set
• Décision “RAG ou pas RAG” (souvent oui, mais petit)

Demi-journée 2: pipeline baseline

• Baseline qui marche de bout en bout, même nulle
• Sortie structurée + citations
• Évaluation automatique minimale

Demi-journée 3: agent + MCP

• Outillage MCP: 2 à 4 tools max
• Permissions simples
• Logs, traces, reproductibilité

Demi-journée 4: durcissement + restitution

• Robustesse: cas manquants, documents vides, questions hors scope
• Résultats: métriques + 3 exemples bons + 1 exemple mauvais expliqué
• README + scénario de démo

Idées de cas “bio-santé” compatibles hackathon (et pas toxiques côté données)

Si tu veux éviter 90% des emmerdes, reste sur du public. Quelques idées qui collent bien au thème MCP agents LLM:

• Agent de revue rapide: interroger PubMed, extraire les endpoints, populations, limites, et produire un tableau sourcé.
• Agent de QC de dataset: détecter incohérences d’unités, champs manquants, valeurs impossibles, puis générer un rapport actionnable.
• Agent de normalisation: mapper des termes libres vers une ontologie, avec justification et source.
• Agent “SOP assistant”: répondre uniquement à partir de procédures internes anonymisées ou publiques, avec citations obligatoires et refus si hors doc.

Ça te donne un cas d’agent IA santé qui se défend, même face à des questions pointues.

Deux rappels utiles si tu bosses avec une DSI, un CHU, ou un lab

Si tu viens avec un cas proche d’un contexte hospitalier ou d’une orga régulée, ne “découvre” pas la conformité le jour J.

• Pour les garde-fous agents: https://lyon-ia.com/blog/agents-ia-10-garde-fous-avant-dautomatiser-en-entreprise-acces-donnees-actions
• Pour les réflexes RGPD côté agentique: https://lyon-ia.com/blog/ia-agentique-et-rgpd-ce-que-la-note-cnil-change-pour-vos-agents-check-list-a-lyon

Ce que tu dois préparer avant de poser ton sac à Lyon 1

• Une phrase de cas d’usage + utilisateur cible
• Un dataset minimal (CSV/JSON) + 5-20 documents de référence
• Un gold set (20-50 cas) + 10 cas “mini” pour itérer
• Une métrique principale (et une secondaire max)
• Un scénario de démo (3 minutes) + un “fail case” assumé
• Une stratégie MCP: 2-4 tools, permissions simples, logs

Le move final: viens pour prouver, pas pour impressionner

Si tu veux réussir ce hackathon IA Lyon 1, joue la carte “utile et vérifiable”. Un agent qui cite ses sources, qui échoue proprement, et qui produit une sortie structurée, c’est 10 fois plus crédible qu’une démo qui parle bien.

Prochaine étape: écris ton cas en 1 phrase, prépare 30 exemples, et décide tes 3 slides de restitution avant même d’arriver campus de la Doua. Après ça, tu peux coder.