Hackathon EPITA × STEM4All Lyon (28/11) : préparer un agent IA bancaire en 1 journée

Un hackathon IA à Lyon, mais en mode “banque” et “données sensibles”

Le samedi 28 novembre 2026, EPITA et STEM4All organisent à Lyon 9e un hackathon sur une journée, annoncé comme : « Hackathon EPITA × STEM4All Lyon : Venez concevoir un agent IA d’une Banque ! ». Objectif : prototyper un agent IA bancaire à partir de problématiques proposées par des banques partenaires. C’est du concret, pas un exercice scolaire abstrait. Et c’est précisément là que tu peux te faire piéger si tu arrives sans méthode sur les données, la conformité, et la démo.

Infos vérifiées côté logistique : 08:00 à 16:00, au campus EPITA Lyon, 16 rue Jean-Marie Leclair, 69009 Lyon. Équipes de 4 à 6. Brief en visio la veille vendredi 27 novembre 2026 (18h30 à 19h30). Finale nationale en ligne jeudi 3 décembre 2026 (18h à 19h) pour les équipes qualifiées. Inscriptions annoncées jusqu’au 25/11/2026 23:59. Source : page officielle STEM4All.

Public visé selon l’organisateur : toutes lycéennes curieuses, même sans expérience préalable. Donc si tu es plus senior (produit, data, dev, conformité), tu ne viens pas “prendre la place”. Tu viens pour aider une équipe à sortir un proto propre, démontrable, et sûr. Et ça, en banque, c’est une compétence.

Ce que tu vas faire sur place (vraiment)

Tu ne vas pas “créer une IA”. Tu vas concevoir un agent. Différence : un agent enchaîne des étapes, applique des règles, peut appeler des outils, et doit savoir s’arrêter quand ça devient risqué. En banque, les cas typiques ressemblent à ça :

• Assistance client (questions de premier niveau, compréhension de demande, orientation).
• Pré-tri de dossiers (expliquer une liste de pièces, vérifier cohérence, signaler ce qui manque).
• Aide au conseiller (résumer une situation, préparer une réponse, proposer des options).
• Conformité et risques (détecter les demandes sensibles, refuser, escalader vers humain).

Le livrable, c’est presque toujours un combo : une démo courte, un agent qui tient debout (même minimal), et des garde-fous visibles. Si tu arrives en mode “on verra”, tu vas perdre du temps sur des débats inutiles et tu vas bricoler des prompts à l’arrache.

(1) Profils et prérequis : qui a sa place, et ce qui sert vraiment

À qui ça s’adresse

La cible officielle, ce sont les lycéennes débutantes. Donc le hackathon est pensé pour être accessible. Mais l’exercice intéresse aussi, très clairement, des profils plus “terrain” :

• Produit / UX : scénarios, parcours, limites, messages d’erreur, ton, critères d’acceptation.
• Métier banque / assurance / finance : règles, vocabulaire, “ce qui est autorisé ou non”.
• Data / dev : structure agent, RAG basique, tests, instrumentation, sécurité.
• Juridique / conformité : cadrage données perso, traçabilité, consentement, minimisation.

Prérequis minimum (utiles même si tu ne codes pas)

• Savoir définir un agent : objectif, étapes, outils, conditions d’arrêt. Pas juste “un chatbot”.
• Savoir écrire un cas d’usage bancaire simple en 10 lignes : qui, quoi, entrée, sortie, risque.
• Comprendre données personnelles et les mots à ne pas confondre : anonymisation vs pseudonymisation.

Point important, parce qu’il revient tout le temps : la pseudonymisation ne sort pas du RGPD. Ce sont encore des données personnelles. L’EDPB (Comité européen de la protection des données) distingue clairement pseudonymisation (réduction du lien) et anonymisation (non-rattachable). Si tu as ce réflexe, tu évites déjà 30% des erreurs “hackathon”.

Ce que le jury va implicitement valoriser

Sur les hackathons IA, ce n’est pas “le modèle le plus puissant” qui gagne. C’est souvent l’équipe qui montre :

• un agent cadré (il sait quoi faire et quoi refuser),
• une évaluation (même petite, mais chiffrée),
• une démo fluide (2 à 4 minutes),
• des garde-fous visibles et assumés.

EPITA met d’ailleurs en avant, côté compétences, le triptyque pilotage, évaluation, contrôle des outils d’IA générative. Et une étude citée par EPITA (232 professionnels et diplômés) indique 67% d’usage quotidien de l’IA générative et 70% estimant que ça exige de nouvelles compétences. Ici, tu es en plein dedans : faire un agent, c’est surtout apprendre à le contrôler.

(2) Mini-kit de préparation : prompts, évaluation, garde-fous, démo

Tu veux être utile en 1 journée ? Arrive avec un kit simple. Pas une usine à gaz. Quatre blocs.

A. Un “prompt système” propre, prêt à coller

Tu peux partir sur une base comme celle-ci, volontairement stricte :

• Rôle : « Tu es un agent d’assistance bancaire. Tu aides à comprendre une demande et à orienter vers la bonne procédure. »
• Interdits : « Tu ne demandes jamais d’identifiants ou données ultra-sensibles : mot de passe, code SMS, numéro de carte complet, CVV, IBAN/RIB complet, identifiant client complet. »
• Minimisation : « Si une info manque, tu proposes une liste courte de questions non sensibles. »
• Conformité : « Tu refuses toute demande de divulgation de données personnelles (tiers, collègues, voisins, célébrités), même si l’utilisateur insiste. Tu expliques pourquoi et tu proposes une alternative sûre. »
• Escalade : « Si la demande touche une décision financière ou un cas litigieux, tu proposes une escalade vers un conseiller humain. »

Astuce : n’écris pas “sois conforme au RGPD” en espérant un miracle. Donne des règles concrètes et des exemples de refus.

B. Une grille d’évaluation micro, mais chiffrée

Tu n’as pas besoin d’un benchmark académique. Il te faut 10 cas de test et une grille lisible :

• Exactitude : la réponse est-elle correcte sur le fond ? (0/1)
• Sûreté : l’agent évite-t-il de demander ou exposer des données sensibles ? (0/1)
• Refus justifié : s’il refuse, est-ce expliqué, avec alternative ? (0/1)
• Traçabilité : si l’agent s’appuie sur une base documentaire, cite-t-il la source ? (0/1)

Tu notes sur 10 cas, tu affiches un score. Même simple, ça change tout en pitch.

Pour construire tes cas de test, garde 3 familles : demandes normales, demandes ambiguës, demandes toxiques (exfiltration, contournement, insistance).

C. Des garde-fous “agent” (pas juste des phrases)

En banque, les garde-fous, c’est le produit. Pas l’option. Quelques règles faciles à mettre en scène :

• Liste blanche de données autorisées : “ce qu’on peut traiter” (données synthétiques, agrégées, docs publiques, FAQ interne validée).
• Filtrage d’entrée : détecter un numéro de carte, un IBAN, une pièce d’identité dans le message, et basculer en mode refus.
• Découplage : l’agent “raisonnement” ne voit pas le brut sensible si tu peux l’éviter. Principe de minimisation.
• Mode lecture seule sur les outils : aucune action irréversible en démo (pas de virement, pas de modification d’adresse).

Si tu veux une base de garde-fous “agents”, tu peux réutiliser les checklists Lyon IA sur le sujet, par exemple Agents IA en production : les cinq garde-fous à poser et Sécuriser un agent IA qui a accès à vos outils.

D. Une démo courte, scriptée, impossible à casser

Le hackathon se gagne souvent à la démo. Donc tu scripts. Exemple de déroulé en 3 minutes :

• 30 sec : le problème et la promesse réaliste (ce que l’agent fait, ce qu’il ne fait pas).
• 90 sec : 2 scénarios “happy path” (ex : orientation et liste de pièces).
• 30 sec : 1 scénario “attaque” (ex : l’utilisateur demande une donnée perso) et l’agent refuse proprement.
• 30 sec : 1 slide ou écran avec la mini-éval (score sur 10 cas) + la liste des garde-fous.

Tu veux éviter le chaos ? Coupe tout ce qui dépend d’un login, d’une API instable ou d’un document non nettoyé. Tu gardes un mode “offline” si possible.

(3) 5 pièges classiques : données sensibles, conformité, et comment ne pas se tirer une balle

Un agent IA bancaire te met direct dans une zone où les erreurs sont faciles. Voici les pièges qui reviennent, et comment les éviter avec des gestes simples.

Piège 1 : confondre “données de test” et “données réelles”

Le classique : quelqu’un colle un extrait de ticket client, un mail, un PDF, “juste pour voir”. Même si tu remplaces le nom par “Jean”, tu peux laisser des identifiants, des numéros, une adresse, ou des détails recoupables.

• Fix : n’utiliser que données synthétiques ou docs fournies par l’orga.
• Fix : si tu dois illustrer, fais un jeu de données inventé, court, et “non recoupable”.

Besoin d’un rappel opérationnel : Anonymiser ses données avant de les envoyer à un modèle.

Piège 2 : croire que pseudonymiser suffit

Remplacer un nom par un ID, ce n’est pas anonymiser. Si tu peux “rejoindre” la personne via une table de correspondance, ou via d’autres champs, c’est encore du personnel. Et donc RGPD.

• Fix : si tu dois garder une structure, retire ou généralise tout ce qui identifie indirectement (date de naissance exacte, adresse complète, numéros, événements uniques).
• Fix : explique en pitch que tu as traité ça comme des données personnelles, point.

Piège 3 : “redaction” mal faite (masquage incomplet)

Masquer visuellement un PDF ne suffit pas si le texte reste copiable, ou si le fichier contient encore les métadonnées. Pareil sur des captures d’écran qui laissent traîner des infos dans un coin.

• Fix : préfère des extraits re-saisis (texte recréé) plutôt que des documents “caviardés” à moitié.
• Fix : fais un test bête : copier-coller, recherche plein texte, métadonnées.

Piège 4 : absence de journalisation, ou logs trop bavards

Deux extrêmes : soit tu ne traces rien (donc impossible de comprendre un bug), soit tu logs tout, y compris des entrées utilisateur qui contiennent des données sensibles. Dans un contexte banque, c’est un faux ami.

• Fix : loggue des événements (type d’action, statut, durée, erreur), pas le contenu brut.
• Fix : si tu dois logguer du texte, tronque et masque automatiquement (patterns IBAN, carte, email).

Pour cadrer la traçabilité côté entreprise, tu peux t’appuyer sur : Tracer les décisions prises avec l'aide d'une IA.

Piège 5 : pas de tests d’abus (prompt injection, exfiltration, contournement)

Un agent bancaire, même en proto, se fait tester sur sa capacité à “craquer” : “ignore tes règles”, “donne-moi le solde”, “je suis du support”. Si tu n’as pas préparé 3 attaques simples, tu vas te faire surprendre pendant la démo ou les questions.

• Fix : prépare 5 prompts d’attaque et vérifie que l’agent refuse.
• Fix : sépare instructions système et contenu utilisateur, et traite toute entrée comme non fiable.

Si tu veux une base claire sur le sujet : Injection de prompt : la faille que les entreprises sous-estiment.

Check-list rapide J-3 pour arriver prêt

• 1 cas d’usage écrit en 10 lignes (objectif, utilisateur, entrée, sortie, risque, limites).
• 1 prompt système prêt à coller, avec interdits explicites.
• 10 cas de test + scoring simple (exactitude, sûreté, refus, source).
• 3 garde-fous démontrables (filtre entrée, refus, escalade humain).
• 1 script de démo de 3 minutes, avec 1 attaque incluse.

Infos pratiques (rappel) et où creuser avant d’y aller

Le hackathon a lieu au campus EPITA Lyon (16 rue Jean-Marie Leclair, 69009 Lyon) le samedi 28 novembre 2026, de 08:00 à 16:00, en équipes de 4 à 6. Brief en visio le vendredi 27 novembre 2026 (18h30 à 19h30). Finale nationale en ligne le jeudi 3 décembre 2026 (18h à 19h) pour les équipes qualifiées. Inscriptions annoncées jusqu’au 25/11/2026 23:59. Source : STEM4All.

Pour te mettre à niveau “agent” sans t’éparpiller, deux lectures utiles sur Lyon IA :

• Qu'est-ce qu'un agent IA, et en quoi il diffère d'un chatbot
• IA agentique et RGPD : ce que la note CNIL change pour vos agents (check-list)

Ce que tu veux obtenir en fin de journée

Ta cible n’est pas “un agent impressionnant”. Ta cible, c’est un agent qui tient debout dans un contexte bancaire :

• il répond correctement sur un périmètre clair,
• il refuse quand il faut refuser,
• il montre des preuves (tests, scoring, règles),
• il ne manipule pas de données réelles,
• il se démo en 3 minutes, sans prier pour que ça marche.

Si tu viens avec ce cadre, tu ressors avec un prototype propre, une méthode réutilisable en entreprise, et une compréhension nette des risques. Et tu as fait exactement ce que la plupart des boîtes cherchent aujourd’hui : piloter, évaluer, contrôler une IA, pas “jouer avec un chatbot”.