Hackathon IA « Agent LLM et MCP » à Lyon 1 (18/11) : qui candidater, quoi préparer

Trois jours pour construire un agent utile. Pas un chatbot démo.

Tu vois passer “agents LLM” et “MCP IA” partout, mais tu n’as jamais eu 72 heures dédiées pour tester ça proprement, avec un cadre, des gens solides et une restitution. C’est exactement la promesse de ce hackathon IA Lyon, organisé à l’Université Lyon 1 La Doua.

Du mercredi 18 novembre 2026 à 14h au vendredi 20 novembre 2026 à 12h, tu as 4 demi-journées (intro, build, restitution) pour prototyper autour de RAG, d’agents, et du Model Context Protocol. L’événement se tient sur le campus de l’Université Lyon 1 – La Doua (Villeurbanne), hébergé par PRABI-AMSB, dans le cadre de l’axe stratégique IA d’IFB/ELIXIR-FR et du projet Mudis4LS. Source organisateur : ifb-elixir.fr.

Ce papier te dit deux choses, cash : qui a le plus à gagner à candidater, et quoi préparer avant de débarquer pour 3 jours de build. Sans supposer ton métier, ton stack, ni tes données.

De quoi parle l’événement, factuellement

• Nom : Hackathon IA « Agent LLM et MCP »
• Dates : du 18/11/2026 14h au 20/11/2026 12h (4 demi-journées)
• Lieu : Université Lyon 1 – La Doua (Villeurbanne), hébergé par PRABI-AMSB
• Cadre : IFB/ELIXIR-FR, axe stratégique IA, projet Mudis4LS
• Thèmes build annoncés : RAG, mode agentique, MCP
• Technos citées : API ALBERT (DINUM), Ollama, FastMCP pour un MCP basique, tool calling et agents via le package OpenAI
• Public cible indiqué : chercheurs et ingénieurs IFB/ELIXIR-FR intéressés par l’IA et ses applications en biologie
• Inscription : pré-inscription obligatoire (échéance indiquée sur la page organisateur)

Source unique pour ces points : IFB/ELIXIR-FR.

Pourquoi “agents LLM + MCP” vaut un hackathon maintenant

Deux raisons simples. Un : les agents deviennent une brique d’automatisation, pas un gadget. Deux : l’interop, c’est le nerf de la guerre quand tu veux brancher un modèle sur des outils réels.

MCP bouge vite. La spec MCP datée du 28 juillet 2026 met en avant un “stateless core” (requête/réponse) et durcit l’autorisation, en s’alignant OAuth2/OIDC. Source : claude.com.

Et l’écosystème pousse fort. Anthropic affirme que MCP a dépassé 400M de téléchargements mensuels des SDK, avec une croissance x4 sur l’année (chiffres déclaratifs). Même source : claude.com.

Traduction terrain à Lyon et en AURA : si tu sais packager un tool MCP propre et le faire appeler par un agent sans casser la sécurité, tu n’es pas juste “curieux IA”. Tu es immédiatement utile en DSI, en produit, en data, en intégration.

Qui devrait candidater (et qui va perdre son temps)

L’organisateur vise surtout chercheurs et ingénieurs côté bio. Mais côté “apprendre et livrer”, le bénéfice dépasse largement la bio si tu viens avec un cas propre et un dataset safe.

1) Ingénierie logicielle (backend, fullstack)

Si tu es dev, tu es avantagé. Pas parce que tu “codes vite”, mais parce que tu sais livrer un proto fiable : API, erreurs, auth, packaging, et une démo qui ne plante pas.

• Tu sais transformer une idée en endpoints, UI minimale, et scénario reproductible.
• Tu sais “emballer” des tools MCP agent-friendly (schémas, descriptions, validation d’inputs, messages d’erreur).
• Tu sais isoler les secrets et éviter la catastrophe de la clé API qui traîne.

2) Data/ML et MLOps (profil sous-coté en hackathon)

Le hackathon te sert si tu veux apprendre à ne pas faire du “demo-only”. Ton rôle : cadrer qualité, latence, coût, reproductibilité. Et mettre juste assez d’observabilité pour comprendre pourquoi l’agent part en vrille.

• Jeu de tests minimal, critères de réussite, mesure avant/après.
• Traces de requêtes, temps, erreurs tool calling, coûts tokens.
• Approche multi-modèles (qualité vs itération locale).

3) Recherche et ingénierie RAG (utile si tu touches des docs complexes)

Si tu aimes la recherche d’info, la citation, le “retrouver juste”, tu vas être dans ton élément. Surtout avec des corpus scientifiques ou techniques.

• Chunking, sources, citations, limites connues.
• Gestion des “pas de réponse” sans hallucination.
• Évaluation simple : précision, couverture, taux de réponses “sourcées”.

4) Sécurité, data governance, conformité (même léger)

Tu veux te différencier ? Viens avec des réflexes sécurité. Un agent qui appelle des outils, c’est un nouveau plan de menace. En 3 jours, tu ne feras pas un modèle “secure by design” complet, mais tu peux poser des garde-fous visibles, et ça compte.

• Qu’est-ce qui part vers une API externe, qu’est-ce qui reste local.
• Logs nettoyés, secrets protégés, permissions minimales.
• Règles d’accès tools MCP : lecture seule par défaut.

5) Product et UX (optionnel, mais ça change tout)

Si tu sais raconter un cas d’usage, tu aides l’équipe à gagner. Une démo claire bat un “proto brillant” incompréhensible.

• Scénario unique, success criteria, langage non technique.
• Écran ou interface minimale, pas 12 notebooks.
• Message final : pour qui, pourquoi, et ce qu’on gagne.

Les profils qui risquent de s’ennuyer

• Tu veux “voir ce que c’est” sans toucher au clavier, sans cas, sans données de démo.
• Tu viens vendre ta boîte ou ton produit. Mauvais format.
• Tu n’es pas prêt à travailler en équipe et à couper des features au couteau.

Le format hackathon : comment tu gagnes en 4 demi-journées

Tu n’as pas le temps de construire un produit. Tu as le temps de prouver un workflow.

• Demi-journée 1 : cadrage, prise en main, constitution des équipes, choix du cas et des données.
• Demi-journées 2 et 3 : build. C’est là que tu dois itérer, mesurer, couper, stabiliser.
• Demi-journée 4 : restitution et bilan. Tu vends la démo, pas la roadmap.

Le bon objectif n’est pas “agent complet”. C’est “un agent qui fait une tâche, correctement, avec des garde-fous”.

Avant J1 : ta checklist “stack & dataset” (sans hypothèses)

A. Objectif de démo : 1 tâche, 1 workflow, 1 métrique

Si tu arrives sans objectif mesurable, tu vas bricoler et perdre 24 heures.

• Une tâche principale : exemple “répondre à une question à partir d’un corpus et citer 3 sources”, ou “exécuter 2 tools MCP et produire un rapport structuré”.
• Un workflow : entrée utilisateur, retrieval ou tools, validation, sortie.
• Une métrique simple : taux de réponses sourcées, taux de tool calls réussis, temps médian de réponse.
• Happy path + 2 cas d’échec : tool indisponible, pas de doc retrouvée. Et réaction attendue de l’agent.

B. Environnement : reproductible ou rien

Objectif : n’importe qui doit pouvoir relancer ton proto.

• Un repo propre, un README, une commande de run.
• Un environnement isolé : Docker si tu sais, sinon venv/conda côté Python, ou équivalent Node.
• Gestion des secrets : variables d’environnement. Jamais de clés en dur. Jamais dans le repo.
• Un plan “offline” si le réseau est instable : modèle local via Ollama (cité par l’organisateur) pour itérer.

C. LLM : prévois un duo “qualité” + “itération”

Tu veux avancer vite et garder une option qualité pour la démo finale.

• Itération : un modèle local via Ollama (si tu as la machine) pour tester prompts, outils, parsing.
• Qualité : une API externe si autorisée (par exemple via ALBERT API, citée par l’événement) pour la restitution.
• Fallback : si un fournisseur tombe, tu switches. Les dépréciations et pannes API, ça arrive.

D. MCP : prépare côté serveur et côté client

MCP, ce n’est pas “juste brancher un plugin”. C’est décrire des tools proprement.

• Serveur MCP minimal : prépare un MCP basique avec FastMCP (cité par l’organisateur).
• Tools MCP agent-friendly :
  • Noms de tools non ambigus.
  • Description actionnable (ce que ça fait, quand l’utiliser, ce que ça ne fait pas).
  • Schéma d’entrée strict (types, champs obligatoires, valeurs autorisées).
  • Erreurs explicites (et gérables par un agent).
• Tool calling : prépare un parsing robuste du retour tool, pas un “string magique”.

Si tu as besoin d’un rappel clair de ce qu’est MCP et pourquoi ça change l’intégration des agents, tu peux repartir de ce guide : https://lyon-ia.com/blog/mcp-protocole-explique.

E. Dataset : safe-by-design (sinon tu prends un risque inutile)

Règle simple : pas de données perso, pas de données santé réelles en clair, pas de secrets internes dans une API externe. Même si “c’est juste une démo”.

• Option 1 : corpus public (docs open, pages web, articles en accès libre).
• Option 2 : corpus synthétique réaliste (faux comptes rendus, faux tickets, faux protocoles).
• Option 3 : corpus interne, mais uniquement si tu peux garantir qu’il reste local et qu’il n’est pas loggé.

Si tu dois anonymiser, fais-le avant. Pas pendant. Point d’entrée utile : https://lyon-ia.com/blog/anonymiser-donnees-avant-ia.

F. Sécurité des données : “minimum viable” mais sérieux

En hackathon, les fuites arrivent par accident : logs, screenshots, prompts copiés, repo public, clé partagée sur un chat. Tu peux éviter 80 % des problèmes avec 8 règles.

• Sépare données de démo, prompts, logs, secrets.
• Réduis les logs : pas de dump complet de documents dans les traces.
• Empêche l’agent d’improviser : allowlist des tools, pas d’accès système large.
• Permissions minimales : lecture seule par défaut.
• Pas d’auto-envoi de pièces jointes, pas d’upload silencieux.
• Secrets : variables d’env, et rotation après l’événement.
• Repo : .gitignore propre, pas de fichiers .env committés.
• Plan de démo : contenu prévu, pas d’impro live sur des données réelles.

Pour cadrer les risques spécifiques aux agents (accès, actions, limites), tu peux t’appuyer sur : https://lyon-ia.com/blog/agents-ia-10-garde-fous-avant-dautomatiser-en-entreprise-acces-donnees-actions.

G. RAG : prépare la plomberie, pas la théorie

Si ton cas inclut un RAG, vise petit et stable.

• Pipeline ingestion: nettoyage, découpage, métadonnées (source, date, type).
• Index: embeddings + stockage.
• Retrieval: top-k simple, puis rerank si tu as le temps.
• Réponse: citations systématiques, et option “je ne sais pas”.

Base utile si tu veux recaler rapidement les fondamentaux : https://lyon-ia.com/blog/rag-ia-documents-entreprise et, côté stockage, https://lyon-ia.com/blog/comparatif-bases-vectorielles.

H. Évaluation : pas besoin de benchmark, juste un jeu de tests

Tu n’as pas besoin d’un papier académique. Tu as besoin de prouver que ça marche sur 10 à 30 cas.

• 10 questions types, 10 attendus, 10 sources attendues si RAG.
• Mesure manuelle rapide + 1 ou 2 checks automatiques.
• Trace des erreurs: tool call échoué, doc introuvable, hallucination détectée.

Pour structurer ton jeu de tests et éviter de te raconter des histoires : https://lyon-ia.com/blog/evaluer-reponses-ia-jeu-de-tests.

Pendant le hackathon : plan de build réaliste (sinon tu t’éparpilles)

Jour 1 : verrouille le scope

• Choisis le cas final en 60 minutes.
• Valide les données de démo et les règles “ce qui sort / ce qui ne sort pas”.
• Monte le squelette : UI minimale ou CLI, premier call LLM, premier tool MCP stub.

Jour 2 : fais marcher la boucle complète

• Un utilisateur pose une question.
• L’agent décide: retrieval ou tool call.
• Le tool répond, l’agent synthétise, cite et sort un format structuré.
• Tu passes déjà ton mini jeu de tests.

Jour 3 : stabilise, sécurise, raconte

• Gestion d’erreurs: timeouts, tool down, inputs invalides.
• Observabilité minimale: logs propres, durée, taux de réussite.
• Démo écrite: script, captures prévues, dataset figé.

Valoriser le résultat à Lyon: en interne ou sur le marché

Le hackathon ne sert à rien si ça finit en repo oublié. Tu veux transformer 3 jours en signal utile.

Option 1 : en interne, tu le vends comme un pilote cadré

• Une page : problème, solution, périmètre, limites, risques, prochaines étapes.
• Une démo rejouable : commande de run + dataset de démo + 5 requêtes exemples.
• Un plan 30 jours : sécurité, conformité, intégration SI, coûts, monitoring.

Si tu dois éviter l’effet “POC vitrine”, garde ce cadre en tête : décider une tâche, une métrique, et une intégration réaliste. La logique est la même que dans ce guide orienté workflows utiles : https://lyon-ia.com/blog/meetup-mindstone-lyon-1811-repars-avec-un-workflow-llm-utile-et-mesurable-en-2-semaines.

Option 2 : sur le marché lyonnais, tu le vends comme une preuve d’exécution

À Lyon, ce qui se valorise vite, c’est la capacité à brancher l’IA sur des outils sans fuite et sans bricolage. MCP est un bon signal, parce que ça touche à l’intégration et à la gouvernance des accès.

• Publie un write-up technique clair (sans données sensibles) : architecture, tools MCP, garde-fous.
• Prépare un pitch de 30 secondes : “voici la tâche, voici la métrique, voici le taux de réussite”.
• Montre que tu sais gérer les risques agentiques (accès, logs, droits). Point d’appui : https://lyon-ia.com/blog/securiser-un-agent-ia.

Et si tu bosses dans un secteur sensible (santé, RH, client), assume le sujet conformité au lieu de l’éviter. Tu peux partir de ce rappel terrain sur données et conformité : https://lyon-ia.com/blog/donnees-conformite-ia-7-lecons-operationnelles-apres-la-sanction-cnil-fnac-darty.

Ce que tu dois avoir dans ton sac (très concret)

• PC prêt, accès admin si possible, Docker installé si tu l’utilises.
• Repo initialisé, template de config (sans secrets).
• Dataset de démo déjà nettoyé et stocké localement.
• Une liste de 10 prompts de test, avec attendus.
• Un script de démo écrit (même brouillon).
• Un plan “si l’API externe est down” (modèle local ou fallback).

Dernier check avant de candidater

Trois questions. Si tu réponds “oui” à deux, tu es un bon candidat.

• Est-ce que je peux expliquer en 20 secondes la tâche que je veux automatiser ?
• Est-ce que je peux venir avec des données de démo safe (public ou synthétique) ?
• Est-ce que je sais livrer une démo rejouable, pas juste un notebook ?

Plan d’action simple, dès maintenant

• J-14 à J-7 : choisis ton cas, prépare ton dataset safe, écris tes 10 tests.
• J-7 à J-2 : monte ton squelette (LLM call, tool calling, logs propres).
• J-2 : fige la démo, coupe les features, prépare ton script de restitution.
• Jour J : exécute. Mesure. Documente. Et sors un proto qui tient debout.

Si tu veux rester aligné avec l’objectif “agent utile, pas agent fantôme”, garde un œil sur les garde-fous agents déjà posés côté Lyon IA : https://lyon-ia.com/blog/agents-ia-en-production-garde-fous.

Le hackathon IA Lyon 1 sur les agents LLM et MCP, c’est une opportunité rare de faire du concret en peu de temps, sur un sujet qui devient une compétence d’intégration majeure. Viens avec un cas clair, un dataset safe, une stack reproductible. Tu repartiras avec un résultat montrable. Et surtout, défendable.