Hackathon HEC IA × APRIL à Lyon (21-22 novembre) : candidater et prototyper en 48 h

Deux jours. Deux cas d’usage assurance. Un prototype qui doit marcher.

Un hackathon, ce n’est pas un cours, ni un lab. C’est un test de livraison. En 48 h, on attend une démo qui tient debout, une logique d’évaluation, et une histoire claire. Pas un modèle “magique” sans preuves.

Les 21 et 22 novembre, le Hackathon HEC IA x APRIL x Bain & Company x Lovable se tient à Lyon, au siège d’APRIL International (12 rue Juliette Récamier, 69006). Le format annoncé : 2 jours, travail en équipe, avec accompagnement d’experts APRIL et Bain & Company. L’inscription se fait via Luma, en mode request to join, donc validation par l’hôte.

Objectif de cet article : te dire comment candidater et comment préparer un prototype IA assurance réaliste en 48 h, sur les thèmes annoncés : fraude documentaire, tarification, et plus largement documents.

Source principale (infos pratiques et cas d’usage) : page Luma de l’événement https://luma.com/yay3vh8r?locale=fr.

Ce qu’on sait (vérifié) sur le hackathon à Lyon

• Nom : Hackathon HEC IA x APRIL x Bain & Company x Lovable. Source : Luma.
• Dates : 21-22 novembre (année non explicitement affichée sur la page). Source : Luma.
• Lieu : siège d’APRIL International, 12 rue Juliette Récamier, 69006 Lyon. Source : Luma.
• Format : 2 jours, en équipe, avec accompagnement d’experts APRIL et Bain & Company. Source : Luma.
• Prise en charge : transport, hébergement et restauration pris en charge par APRIL. Source : Luma.
• Sélection : inscription avec validation requise (“request to join”). Source : Luma.
• À la clé : cash prizes et opportunités de stage/emploi potentielles (tel qu’indiqué). Source : Luma.

Les deux cas d’usage annoncés (et ce que ça implique en 48 h)

1) Fraude documentaire (santé et moto)

Le sujet : détecter des documents frauduleux, y compris des documents générés ou modifiés par IA, sur deux marchés : santé et moto (source : Luma).

Traduction hackathon : tu ne vas pas “résoudre la fraude”. Tu vas construire un flux de contrôle qui aide un gestionnaire à trier vite :

• ingestion doc (PDF, image, photo),
• extraction (OCR + champs clés),
• signaux de suspicion (incohérences, altérations, anomalies),
• score de risque + explication lisible,
• décision “auto OK / revue humaine / rejet”.

Le vrai piège : faire une démo “wahou” sans protocole d’évaluation ni limites. En assurance, ça ne passe pas.

2) Tarification assurance bateau (photo + caractéristiques)

Le sujet : à partir d’une photo et de caractéristiques d’un bateau, proposer automatiquement le segment tarifaire pertinent (source : Luma).

Traduction hackathon : tu ne vas pas estimer un prix final. Tu vas faire une classification en segments (ou règles + ML) avec des garde-fous :

• entrée : image + formulaire simple,
• sortie : segment + raisons + niveau de confiance,
• fallback : “je ne sais pas”, renvoi vers un conseiller.

À qui ça s’adresse (profil “hackathon IA Lyon assurance” qui a une chance)

Ce hackathon IA à Lyon côté assurance récompense surtout les équipes qui savent livrer. Les profils typiques qui maximisent les chances :

• 1 à 2 profils data/ML : NLP, vision, détection d’anomalies, évaluation.
• 1 profil software : API, app de démo (Streamlit/Gradio), intégration.
• 1 profil produit/métier assurance : cadrage, KPIs, risques, scénario de démo crédible.
• 1 profil data/ops (optionnel mais décisif) : pipeline, traçabilité, sécurité, reproductibilité.

Si tu viens seul, vise un prototype plus petit, mais carré. Si tu viens en équipe, évite l’équipe “que data”. Il faut une démo utilisable.

Prérequis techniques réalistes (et les erreurs qui te tuent)

Ce que tu dois savoir faire

• Assembler vite des briques existantes (modèles pré-entraînés, OCR, embeddings), sans vouloir tout entraîner.
• Livrer une démo fonctionnelle : une web app simple + un pipeline exécutable + un README.
• Mettre une évaluation minimale : jeu de test, métriques, limites, exemples d’erreurs.

Stacks qui marchent en 48 h

• Python + Streamlit ou Gradio pour la démo.
• FastAPI si tu veux une API propre.
• OCR : Tesseract, PaddleOCR, services API si autorisés par l’orga.
• LLM : API ou modèle open, mais garde un plan B si quotas ou latence.

Erreurs classiques

• “On va entraîner un modèle from scratch”. Non. 48 h, c’est baseline + itérations.
• Pas de données de test. Tu finis avec un prototype invérifiable.
• Démo sans histoire métier. Le jury n’achète pas.
• Ignorer la confidentialité. Mauvais signal direct en assurance.

Comment candidater (Luma “request to join”) sans perdre une semaine

Sur Luma, tu ne “prends pas un billet”. Tu demandes à rejoindre. Donc tu dois être lisible en 20 secondes.

Message de candidature (structure simple)

• Qui tu es : rôle actuel, compétences, ce que tu sais livrer.
• Ton stack : “Python + Streamlit + OCR + scoring”, ou “vision + classification + explainability”.
• Ton rôle en équipe : data, app, produit, ops. Un seul.
• Preuves : 3 liens max (GitHub, démo, notebook solide).
• Ce que tu construis en 48 h : une phrase, métrique incluse.
• Ce que tu ne feras pas : périmètre maîtrisé, risques RGPD gérés.

Exemple de pitch candidat (à adapter)

“Je peux livrer en 48 h une démo Streamlit de détection de fraude documentaire : upload PDF/photo, extraction OCR des champs, score de risque et explications. Éval sur un jeu de test interne (precision/recall + taux de faux positifs). Je ne fais pas d’entraînement lourd, je pars sur modèles pré-entraînés + règles et j’ajoute des garde-fous confidentialité.”

Organisation d’équipe : qui fait quoi, et quand

Un hackathon qui se passe bien a une règle : la démo tourne le samedi midi (même si l’événement se termine plus tard). Après, tu polish.

Répartition de rôles (simple, efficace)

• Owner produit : scénario de démo, critères de succès, pitch, Q&A.
• Owner data : dataset, features, métriques, erreurs, ablations.
• Owner app : UI, endpoints, intégration, packaging.
• Owner ops : repo, scripts, reproductibilité, secrets, logs.

Livrables typiques attendus (même si ce n’est pas écrit)

• Démo live 3 à 5 minutes, scénario clair.
• Repo propre : README, install, commande “run”, exemples.
• Évaluation : métriques + quelques cas d’échec montrés honnêtement.
• Pitch : problème, approche, résultats, risques, next steps.

Checklist “prêt en 48 h” pour un prototype IA assurance

Tu veux gagner un hackathon IA Lyon assurance ? Arrête de viser “le modèle parfait”. Vise le système démontrable.

1) Jeu de données : petit, propre, documenté

• Définis ton unité : 1 document = 1 exemple, ou 1 sinistre = ensemble de docs.
• Label minimal : “frauduleux / non frauduleux” ou “segment A/B/C”. Si tu ne peux pas, fais du “weak labeling” mais dis-le.
• Split : train/test dès le départ. Même si c’est 80/20.
• Dataset card : source, volume, biais, limites, types de docs/images.
• Cas tordus : au moins 10 exemples “difficiles” pour la démo (photos floues, PDF scannés, champs manquants).

Astuce : prépare un dossier “demo_samples/” avec 6 à 8 fichiers que tu es sûr de pouvoir montrer en public.

2) Évaluation : une page, pas un roman

• Fraude : precision, recall, F1. Et surtout : taux de faux positifs (sinon tu bloques la prod).
• Tarification segment : accuracy macro, confusion matrix (où tu te trompes), calibration simple (confiance).
• Extraction : exact match sur champs critiques (date, montant, immatriculation, numéro de contrat).

Si tu utilises un LLM pour extraire ou expliquer, garde une baseline non-LLM (regex + règles) pour comparer. Tu évites le “ça dépend du prompt”.

Pour structurer ça proprement, tu peux t’appuyer sur la logique “jeu de tests” détaillée dans notre guide : https://lyon-ia.com/blog/evaluer-reponses-ia-jeu-de-tests.

3) Confidentialité et sécurité : zéro surprise

• Ne mets jamais de données perso réelles dans un repo.
• Secrets : clés API dans variables d’environnement, pas en dur.
• Rétention : explique si les documents sont stockés, combien de temps, et où.
• Logs : pas de contenu document dans les logs, seulement des IDs et métriques.

Si tu veux une checklist rapide “avant d’ouvrir des données à un assistant IA”, tu as celle-ci : https://lyon-ia.com/blog/fuite-de-donnees-7-controles-rapides-avant-douvrir-vos-donnees-a-un-assistant-ia.

4) Architecture simple qui gagne : extraction, RAG, scoring

En 48 h, tu veux une architecture lisible au tableau. Exemple générique, applicable aux deux cas.

• Ingestion : upload doc/image.
• Pré-traitement : redressement image, compression, normalisation.
• Extraction : OCR + parse champs (LLM ou règles) + validation.
• RAG (optionnel mais utile) : récupérer la règle métier, la liste des pièces attendues, les barèmes de segments, puis justifier.
• Scoring : modèle léger ou règles + pondération + seuils.
• Triage : décisions en 3 classes (OK, revue humaine, rejet).
• UI : afficher documents, champs extraits, score, raisons, et “action suivante”.

Pour la partie RAG, ne surcomplexifie pas. Un RAG de hackathon, c’est :

• un petit corpus (PDF de règles, notes internes fictives, barèmes),
• embeddings + recherche vectorielle,
• réponse avec citations des passages retrouvés.

Si tu as besoin de remettre à plat “RAG vs fine-tuning” pour éviter de perdre du temps : https://lyon-ia.com/blog/fine-tuning-ou-rag et le guide RAG : https://lyon-ia.com/blog/rag-ia-documents-entreprise.

5) Prototype “fraude documentaire” : une recette qui tient

Tu veux un prototype IA fraude documentaire démontrable. Voici un plan robuste.

• Étape A : OCR + extraction champs (date, montant, identifiants, tampon, signature, zones clés).
• Étape B : contrôles de cohérence (format date, montants plausibles, correspondance entre champs).
• Étape C : signaux “IA/retouche” basiques mais utiles (métadonnées absentes, différences de résolution par zone, texte incohérent avec le template).
• Étape D : score final (0-100) + top 3 raisons.
• Étape E : action recommandée (revue humaine, demande de pièce, rejet).

Montre un écran “comparatif” : doc normal vs doc suspect, et ce que ton système a repéré. Les jurys adorent quand c’est visuel et explicable.

À relier au contexte : la fraude documentaire assistée par IA est un sujet qui monte. Des analyses sectorielles indiquent une hausse forte des falsifications, et des enquêtes auprès de professionnels anticipent une augmentation dans les prochains mois (par exemple ACFE/SAS, LexisNexis Risk Solutions, Inscribe). Moralité hackathon : ton prototype doit intégrer le triage et l’explicabilité, pas seulement un score.

6) Prototype “tarification bateau” : classer, expliquer, refuser quand il faut

• Entrées : photo + longueur + type (voilier, semi-rigide, etc.) + puissance + année.
• Vision : modèle pré-entraîné pour extraire quelques attributs visuels simples (présence cabine, type coque, marque lisible si possible).
• Modèle : classifier en segments (ou règles + arbre de décision) avec une baseline.
• Explication : “segment B car longueur 7-9 m + puissance X + type Y + confiance 0,78”.
• Fallback : si confiance < seuil, renvoi vers estimation manuelle.

Ce qui fait la différence : la gestion de l’incertitude. Un bon prototype ne répond pas toujours. Il sait aussi dire non.

Une démo convaincante : le scénario, pas la techno

Tu as 3 à 5 minutes. Personne n’a le temps de comprendre ton architecture microservices.

Structure de démo qui marche

• 1 phrase problème : “La fraude documentaire augmente, et les équipes passent trop de temps à trier.”
• 1 phrase promesse : “On réduit le temps de tri en priorisant les dossiers à risque et en expliquant pourquoi.”
• Live : tu upload 2 exemples, tu montres extraction, score, explications, action.
• Résultats : 3 métriques max, sur ton jeu de test.
• Limites : 2 limites honnêtes, et comment tu corrigerais en phase 2.

Critères implicites de jury (ce qu’ils regardent vraiment)

• Ça marche en live : pas de crash, pas de latence absurde.
• Tu mesures : même simplement.
• Tu expliques : pourquoi le système décide.
• Tu gères le risque : confidentialité, erreurs, revue humaine.

Plan d’attaque minute par minute (48 h)

Avant d’arriver (si tu peux)

• Repo prêt, template Streamlit/Gradio, gestion des secrets.
• Pipeline OCR qui tourne sur ta machine.
• Dossier “demo_samples/” avec fichiers de démo.

Jour 1 matin

• Cadrage : 1 cas d’usage, 1 métrique principale, 1 scénario démo.
• Dataset : constitution du test set.
• Baseline : première version “bête mais qui marche”.

Jour 1 après-midi

• Itération : amélioration extraction ou scoring.
• UI : premier parcours utilisateur complet.
• Évaluation : premières métriques, premiers échecs documentés.

Jour 2 matin

• Stabilisation : figer la démo.
• Polish : explications, affichage, temps de réponse.
• Pitch : slides minimales, 5 points, pas plus.

Jour 2 après-midi

• Répétition démo x5.
• Plan Q&A : données, biais, faux positifs, confidentialité, passage prod.

Deux points d’attention locaux : APRIL à Lyon, et le bon APRIL

Le hackathon se passe au siège d’APRIL International à Lyon 6e, rue Juliette Récamier (source Luma). Le groupe APRIL indique opérer dans 25 pays, avec 3 300 collaborateurs, et un chiffre d’affaires groupe 2025 de 907 M€ (source : page groupe APRIL International).

Point bête mais réel : dans certaines recherches, “APRIL” renvoie aussi à une société de pâte à papier en Indonésie. Ici, on parle bien d’APRIL l’assureur basé à Lyon.

Ce que tu dois faire maintenant (si tu veux y aller)

• Choisis ton cas : fraude documentaire ou tarification bateau. Pas les deux.
• Écris ton message Luma : rôle, stack, preuve, livrable en 48 h, limites.
• Prépare ta démo : 6 à 8 fichiers exemples, et un chemin utilisateur complet.
• Prépare ton évaluation : split + 3 métriques + 5 erreurs que tu assumes.
• Prépare ta confidentialité : secrets, rétention, pas de données perso dans le repo.

Si tu veux t’entraîner au format hackathon “démo qui tient”, tu peux aussi regarder notre retour méthode sur un autre hackathon à Lyon : https://lyon-ia.com/blog/hackathon-unboxed-centrale-lyon-ia-sortir-un-poc-ia-utile-en-30-heures-meme-sans-data.

Pour les infos officielles du Hackathon HEC IA Lyon avec APRIL International (inscription, lieu, modalités), reste sur la source : https://luma.com/yay3vh8r?locale=fr.