Hackathon HEC IA x APRIL x Bain à Lyon (21-22/11) : préparer un cas assurance en 48 h

Tu as 48 h. Un cas assurance. Des données imparfaites. Un jury qui veut du concret. Et une contrainte simple : si ta démo ne montre pas un gain mesurable, tu vas te faire doubler par une équipe moins « smart » mais mieux préparée.

Le Hackathon HEC IA x APRIL x Bain & Company se tient à Lyon du samedi 21 novembre 2026 au dimanche 22 novembre 2026, au siège d’APRIL International, 12 Rue Juliette Récamier, 69006 Lyon. Format annoncé : deux jours, en équipes, avec accompagnement d’experts APRIL et Bain (IA, tech, métier). Sources : luma.com, aihackclub.com.

Deux défis sont annoncés côté assurance : fraude documentaire IA (santé, moto) et tarification IA (bateau). Source : luma.com. Donc oui, si tu cherches des mots-clés, on est pile dans hackathon IA Lyon assurance, APRIL hackathon Lyon, fraude documentaire IA, tarification assurance IA.

1) Le format réel : ce que tu dois anticiper

Un hackathon « assurance » efficace, ce n’est pas « entraîner un modèle ». C’est :

• cadrer un objectif faisable en 48 h,
• sortir une démo qui tourne à tous les coups,
• mesurer quelque chose, même sur un petit jeu d’exemples,
• expliquer les limites sans te saborder.

Le point clé dans l’annonce : tu auras des experts (métier assurance, tech, IA). Ça favorise les équipes qui savent poser les bonnes questions et itérer vite, pas celles qui codent en tunnel.

Profils attendus (pratique, pas théorie)

Vu les deux sujets (documents, images, classification, scoring), l’équipe qui marche le mieux ressemble à ça :

• 1 lead ML/data : baseline, features, évaluation, calibration.
• 1 dev produit : pipeline, API, UI légère, packaging de la démo.
• 1 profil LLM/vision : OCR, extraction, classification image, prompts.
• 1 profil “métier assurance” (si tu peux) : définitions, règles, métriques utiles, risques de non-sens.

Tu peux faire à 3, mais à 3 tu dois être très discipliné : une seule piste, une seule démo, une seule métrique.

2) Les deux défis annoncés : où tu peux gagner du temps

Défi 1 : fraude documentaire IA (santé et moto)

Objectif annoncé : détecter des documents frauduleux, y compris générés ou modifiés par IA, sur deux marchés : santé et moto. Source : luma.com.

Ce que tu dois te mettre en tête : en 48 h, tu ne feras pas un « détecteur parfait ». Le bon angle, c’est un score de suspicion + explication + workflow de revue humaine.

Ce qui marche bien en démo :

• Tu importes un PDF ou une photo de document.
• Tu extrais des champs (OCR).
• Tu fais des contrôles simples (règles) + un modèle léger (ou classif).
• Tu sors un score et 3 signaux qui justifient la suspicion (incohérence, artefact, duplication, anomalie).
• Tu proposes une action : « envoi en contrôle », « demande de justificatif », « vérification manuelle ».

Défi 2 : tarification IA (bateau)

Objectif annoncé : à partir d’une photo et des caractéristiques d’un bateau, proposer automatiquement le segment tarifaire le plus pertinent pour accélérer la tarification. Source : luma.com.

Traduction « hackathon » : tu dois faire un outil qui aide le tarificateur. Pas un système qui décide tout seul.

Ce qui marche bien en démo :

• Tu upload une photo + tu saisis 4-6 caractéristiques.
• Tu obtiens un top 3 segments avec un score de confiance.
• Tu affiches les raisons : attributs visuels détectés + variables structurées importantes.
• Tu montres un avant/après sur le temps ou la qualité du routage.

3) Préparation efficace avant J1 : arrive avec un plan, pas avec des idées

Choisis ton combat

Ne viens pas « open ». Décide avant :

• Fraude documentaire : tu joues la carte pipeline + signaux + triage.
• Tarification : tu joues la carte multimodal simple + top-k + routage.

Si tu hésites : fraude documentaire est souvent plus « démontrable » vite (tu peux fabriquer des cas). Tarification peut être plus compétitive si tu arrives à sortir une baseline solide et une explication claire.

Prépare ton repo comme si tu devais livrer lundi matin

• Un repo Git avec structure propre (src/, notebooks/, data/, scripts/).
• Un script “one command demo” (Makefile ou task runner) : download data, run pipeline, start UI.
• Un fichier .env.example (clé API, variables).
• Des seeds partout (reproductibilité).
• Un mini jeu d’exemples versionné (même 30 fichiers), pour garantir la démo offline.

Prépare une baseline avant de rêver à du SOTA

La baseline, c’est ton assurance vie. Elle doit tourner vite et être compréhensible.

• Fraude documentaire : règles simples (cohérences, formats, duplicats) + modèle léger (classification sur features OCR ou anomalies).
• Tarification : modèle sur variables structurées + extraction d’attributs depuis l’image (même simple) puis classif final.

Ton but : battre « hasard + intuition ». Pas battre un modèle industriel.

4) Données : comment ne pas mourir sur l’étape la plus sous-estimée

En hackathon assurance, la data est souvent :

• petite,
• bruyante,
• déséquilibrée (peu de fraudes),
• pas totalement documentée.

Plan data minimal

• Un schéma : quels champs, quelles étiquettes, quelles sorties.
• Un split train/test figé (même simple).
• Un dictionnaire de variables sur 1 page (même incomplet mais clair).
• Une liste de cas de démo : 10 cas normaux, 10 cas “problèmes”.

Si tu es sur fraude documentaire : fabrique une typologie

Tu gagnes du temps si tu classifies les fraudes par familles :

• Falsification (champs modifiés, montants, dates).
• Altération (image retouchée, zones floutées, incohérences de police).
• Incohérences (adresse, identité, format, logique métier).
• Document synthétique (généré, recomposé, “trop propre”).
• Duplications (même doc réutilisé, variations mineures).

Ça te permet de produire des signaux et une explication, même si ton modèle n’est pas parfait.

5) Prompts : utiles, mais seulement si tu les rends testables

Les prompts non testés, c’est du vent. Tu veux des prompts qui sortent des structures (JSON) et qui se mesurent.

Exemples de prompts prêts à l’emploi

Extraction structurée (fraude doc)

But : sortir des champs OCR nettoyés + drapeaux d’anomalies de format.

Prompt (à adapter) :

“Tu es un extracteur de champs pour un dossier d’assurance. À partir du texte OCR ci-dessous, retourne uniquement un JSON avec : nom, prénom, date_naissance, date_document, montant, type_document, adresse, immatriculation (si présent), et un tableau anomalies_format (ex : date invalide, montant incohérent, champ manquant). Si un champ est absent, mets null. Texte OCR : …”

Explication courte (tarification)

But : justifier un top 3 segments sans roman.

Prompt :

“Tu es un assistant pour tarificateur assurance bateau. On te donne : attributs_visuels_detectes, caracteristiques_declarees, prediction_segments_top3. Rédige 4 puces maximum : 2 raisons principales, 1 incertitude, 1 action de contrôle humain. Ne mentionne pas de données personnelles. Données : …”

Le piège classique

Utiliser un LLM comme juge et partie. Exemple : le LLM extrait, classe, puis s’auto-évalue. Mauvaise idée. Tu veux une évaluation qui ne dépend pas du modèle qui produit.

6) Évaluation : une métrique simple vaut mieux qu’un discours

Le jury va te demander « comment tu sais que ça marche ». Prépare une réponse chiffrée.

Fraude documentaire : métriques qui collent au terrain

• Précision@k : dans les k dossiers envoyés en revue, combien sont vraiment suspects.
• Matrice de confusion sur un jeu test (même petit).
• Taux de faux positifs acceptable (à discuter) : si tu bloques tout, tu as perdu.

Et surtout : montre une file de contrôle. L’assurance vit avec des files, pas avec des prédictions abstraites.

Tarification : au-delà de l’accuracy

• Accuracy / F1 macro par segment (si multi-classes).
• Taux de routage correct en première intention (métrique opérationnelle).
• Coverage : pour combien de cas tu oses proposer un segment avec confiance suffisante.

Si tu ajoutes un seuil de confiance + “sinon revue humaine”, tu parais tout de suite plus sérieux.

7) Conformité et garde-fous : dis-en assez pour être crédible

Sur tarification, tu touches vite à la décision automatisée et au profilage. La CNIL rappelle que l’article 22 du RGPD encadre les décisions fondées exclusivement sur un traitement automatisé produisant des effets juridiques ou affectant significativement les personnes. Source : cnil.fr.

La CNIL indique aussi que pour des traitements impliquant profilage ou décision automatisée, une AIPD (DPIA) est toujours requise. Source : cnil.fr.

Et elle propose une démarche pour se mettre en conformité IA et RGPD (utile pour cadrer ton slide “garde-fous”). Source : cnil.fr.

Comment en parler sans plomber ta démo

• Dis clairement : “POC, pas décision 100% auto”.
• Ajoute : revue humaine pour les cas à faible confiance.
• Montre un début de traçabilité : logs des entrées, version modèle, score, raisons.
• Sur les données : minimisation (tu n’utilises que ce qui est nécessaire).

Tu n’as pas à “faire le RGPD” en 48 h. Tu dois montrer que tu sais qu’il existe, et que ton approche ne l’ignore pas.

8) La méthode de démo en 48 h : le déroulé qui marche

Démo fraude documentaire (5 minutes)

• 1 minute : contexte, typologie, objectif (triage, pas vérité absolue).
• 2 minutes : upload doc, extraction, score + 3 signaux, proposition d’action.
• 1 minute : métriques sur mini jeu test (précision@k, confusion).
• 1 minute : limites + prochaines étapes (données, AIPD, déploiement).

Démo tarification (5 minutes)

• 1 minute : objectif (aide au tarificateur, accélération).
• 2 minutes : photo + caractéristiques, top 3 segments + explication courte.
• 1 minute : métriques + seuil de confiance + cas “revue humaine”.
• 1 minute : risques (biais, dérive, RGPD article 22) + garde-fous.

9) Check-list : arrive avec une équipe, un angle, une démo mesurable

Avant J1

• Équipe 3-5 avec rôles clairs (ML, dev, démo, éval, métier).
• Un seul défi choisi, et un sous-objectif écrit en 2 lignes.
• Repo prêt + script de lancement.
• Mini dataset de démo (30-50 exemples) + 20 cas “showcase”.
• Plan d’évaluation défini (2 métriques max).
• Slides squelette (problème, solution, pipeline, métriques, risques).

Jour 1 (matin)

• Valide avec les experts : définition de la cible (fraude, segments, erreurs coûteuses).
• Fixe la métrique “qui compte”.
• Freeze le scope à midi. Après midi, tu exécutes.

Jour 1 (après-midi + soir)

• Baseline qui tourne de bout en bout.
• UI minimaliste (même moche) mais stable.
• Premier calcul de métriques sur split figé.

Jour 2 (matin)

• Améliorations ciblées : 2 leviers max (ex : OCR mieux, calibration, features).
• Ajout “garde-fous” : seuil de confiance, revue humaine, logs.

Jour 2 (après-midi)

• Répétition démo 3 fois sans bug.
• Prépare 5 questions du jury et tes réponses.
• Fige versions : modèle, dataset, code.

10) Deux erreurs qui tuent (même avec une bonne idée)

• Pas de reproductibilité : “ça marchait sur mon laptop”. Script, seeds, dataset démo.
• Surpromesse : “tarification instantanée fiable” ou “détection de fraude IA parfaite”. Dis plutôt “aide à la décision” + limites.

Ce que tu fais maintenant (plan d’action rapide)

Si tu veux arriver prêt au hackathon IA Lyon assurance (APRIL hackathon Lyon), fais ça cette semaine :

• Choisis fraude documentaire IA ou tarification assurance IA.
• Écris ton objectif en 2 lignes + ta métrique en 1 ligne.
• Monte un repo avec un script de démo.
• Prépare 20 cas de démo et un split figé.
• Décide ton “storyboard” de présentation (5 minutes, pas plus).

Pour les infos événement (lieu, format, prise en charge annoncée), repars de la page source : luma.com. APRIL y indique aussi être présent dans 25 pays et compter 3 300 collaborateurs (à revalider selon modalités et communications du moment). Source : luma.com.

Et si tu veux un aperçu du hackathon déjà publié côté Lyon IA (candidature, format, prototypage), tu peux partir de cet article : https://lyon-ia.com/blog/hackathon-hec-ia-april-a-lyon-21-22-novembre-candidater-et-prototyper-en-48-h.