Table ronde Lyon Data Science au TUBÀ (17/11) : viens avec ton blocage IA, repars avec 3 décisions

Tu as un blocage IA. Pas besoin d’un énième talk.

Tu as un modèle qui “marche” en notebook, puis se dégrade en prod. Un LLM qui coûte trop cher. Un pipeline fragile. Un métier qui ne fait pas confiance aux scores. Bref : un blocage MLOps ou un problème d’évaluation IA en production qui te mange du temps.

Le mardi 17 novembre 2026, Lyon Data Science organise une table ronde au TUBÀ à Lyon Part-Dieu, de 18h30 à 20h00, au 15 Bd Marius Vivier Merle, 69003 Lyon. Format annoncé : petit groupe, pas de conférence, aucun slide, sujets amenés par les participants, discussions et synthèse en fin de session. Capacité : 25 places, gratuit sur inscription. Source : page Meetup “Data & IA à Lyon : projets, blocages et retours terrain, Table ronde”.

L’intérêt, si tu viens préparé : repartir avec 3 décisions actionnables dès le lendemain au bureau, sur données, modèle, run (déploiement, monitoring, exploitation). C’est ça l’objectif.

Les infos utiles (sans blabla)

• Nom : Data & IA à Lyon : projets, blocages et retours terrain, Table ronde
• Date : mardi 17 novembre 2026
• Heure : 18h30 à 20h00 (CET)
• Lieu : TUBÀ, 15 Bd Marius Vivier Merle, 69003 Lyon (Part-Dieu)
• Format : petit groupe, zéro slide, sujets des participants, synthèse finale
• Places : 25 max, gratuit sur inscription
• Communauté : Lyon Data Science existe depuis 2015 et affiche environ 4 600 membres sur Meetup
• Proposer un sujet : sur place au tour de table, ou en amont via commentaires Meetup ou Discord

SEO, au passage : si tu cherches “Lyon Data Science TUBA”, “table ronde data IA Lyon”, c’est exactement ce format : du terrain, du diagnostic collectif, et pas du storytelling.

Si tu veux une liste de questions prêtes à l’emploi (plutôt orientées discussion), tu peux aussi lire : https://lyon-ia.com/blog/data-ia-a-lyon-1711-tuba-12-questions-pour-debloquer-ton-projet.

Le piège numéro 1 : venir avec “un sujet” au lieu d’un blocage

Un sujet flou ressemble à ça : “On veut industrialiser l’IA”, “On hésite entre X et Y”, “On aimerait faire du RAG”. Le groupe va brainstormer, et tu repartiras avec des idées. Pas des décisions.

Un blocage, c’est un symptôme observable, relié à une métrique, sous contrainte. Là, le groupe peut trancher.

La formule qui marche (30 secondes)

• Symptôme : ce que tu observes, en une phrase, sans jargon.
• Métrique : comment tu le vois dans les chiffres (même imparfait).
• Contrainte : ce qui t’empêche de “juste faire mieux” (budget, latence, sécurité, data, orga).

Exemples de symptômes “table ronde compatibles”

• “Le modèle est bon offline, mais en prod les alertes explosent.”
• “Le support refuse l’outil : trop de faux positifs, ils perdent du temps.”
• “On n’a pas de vérité terrain rapide, donc on ne sait pas si on régresse.”
• “On a des coûts LLM qui montent, sans savoir quel levier actionner.”
• “Chaque déploiement casse quelque chose, on n’ose plus livrer.”

Ça, c’est le genre de cas où un groupe expérimenté peut t’aider à décider si ton problème est données, modèle ou run.

Prépare ton blocage en 15 minutes : le kit “symptôme, métrique, contrainte”

Étape 1 : écris le symptôme comme si tu parlais à un collègue métier

Objectif : être compris en 10 secondes. Tu supprimes les noms d’outils. Tu gardes l’effet réel.

• Mauvais : “On a un problème de drift + feature store.”
• Bon : “Les prédictions se dégradent depuis 3 semaines, on ne sait pas pourquoi.”

Étape 2 : viens avec une métrique, même moche

Sans métrique, tu es condamné au ressenti. Pour une évaluation IA en production, la métrique peut être :

• Qualité : précision, rappel, F1, taux de faux positifs, taux d’hallucination (si GenAI), taux d’erreur critique.
• Opérations : latence p95, taux de timeout, taux d’échec de pipeline, volume d’incidents, temps de reprise.
• Métier : taux de traitement automatique, temps gagné, coût par dossier, taux d’escalade, satisfaction interne.

Tu n’as pas tout ? OK. Mais viens avec une courbe ou un chiffre et une période : “depuis quand”.

Étape 3 : annonce la contrainte qui verrouille la solution

Sinon, on va te répondre “il faut annoter plus” ou “il faut monitorer” et tu vas dire “oui mais…”. Gagne du temps.

• Contrainte data : pas d’accès, données dispersées, labels trop chers, définition métier instable.
• Contrainte prod : latence max, infra imposée, pas de GPU, release cycle lourd.
• Contrainte SSI / conformité : données perso, hébergement, logs, traçabilité, restrictions outils.
• Contrainte orga : pas de propriétaire clair, pas de runbook, pas de support, pas de budget.

Le format “3 décisions” : données, modèle, run

Tu veux sortir de la table ronde avec 3 décisions. Pas 30 idées. Pour y arriver, tu cadres la discussion comme ça :

Décision 1 : données (ce que tu changes d’ici 2 semaines)

La plupart des blocages “modèle” sont des blocages data déguisés. Décisions typiques :

• On définit une source de vérité et on arrête les extractions à la main.
• On met en place un jeu de tests data (manquants, doublons, schéma, distributions) avant chaque run.
• On crée un process de label : qui annote, quand, avec quel contrôle qualité.
• On tranche la définition métier (ce qu’est une “fraude”, un “lead qualifié”, un “incident”).

Décision 2 : modèle (objectif, métrique, seuil)

Le point dur, ce n’est pas “quel algo”. C’est quelle décision métier ton modèle pilote, et à quel niveau de risque.

• On change la métrique d’optimisation (ex : réduire les faux positifs plutôt que maximiser l’AUC).
• On choisit un seuil go/no-go production et on l’assume.
• On passe en assisté d’abord (recommandation), puis automatisation progressive.
• On simplifie : un modèle plus petit, plus stable, plus explicable, si le run est le vrai problème.

Décision 3 : run (déploiement, monitoring, rollback)

Le run, c’est là que naissent les incidents. Et c’est exactement là qu’un groupe peut te donner des patterns éprouvés.

• On standardise le logging minimum (inputs, outputs, latence, version modèle/prompt, contexte).
• On ajoute un fallback (manuel, règle, ancien modèle) et un rollback clair.
• On met un SLO réaliste : latence, taux d’erreur, disponibilité.
• On clarifie qui est owner : données, modèle, décision métier, incident prod.

C’est souvent ça, le vrai déblocage MLOps : pas “plus d’outils”, mais plus de responsabilité explicite.

Les questions qui forcent des arbitrages (au lieu d’un brainstorming)

Viens avec 1 question de décision. Une seule. Le reste, c’est du bruit.

Questions “diagnostic” (données, modèle, run)

• “D’après vous, c’est d’abord un problème de données, de modèle ou de run ? Pourquoi ?”
• “Quelle est la première mesure que vous mettriez en place pour confirmer l’hypothèse ?”

Questions “évaluation IA en production”

• “Quelle métrique online doit piloter le go/no-go ? Et à quel seuil ?”
• “Comment vous récupérez le feedback et sous quel délai (immédiat, différé, audit) ?”
• “C’est quoi votre plan de rollback si la qualité chute ?”

Questions “blocage MLOps” (concret, exploitable)

• “Qu’est-ce que vous loggez vraiment pour diagnostiquer un incident ?”
• “Qui est propriétaire de quoi : donnée, modèle, décision métier, incident ?”
• “Le meilleur ROI chez vous : tests de données, monitoring, CI/CD, ou process (revue, runbook) ?”

Mini canevas à remplir avant de venir (copie-colle dans tes notes)

Tu veux que le groupe t’aide ? Donne-lui de la matière. Ce canevas tient sur une page. Tu peux l’imprimer ou le garder sur ton tel.

Données

• Sources : …
• Volume / fraîcheur : …
• Problème principal (manquants, bruit, doublons, drift, droits d’accès) : …
• Vérité terrain (labels) : qui, comment, délai : …

Évaluation

• Objectif métier (décision à améliorer) : …
• Métriques offline : …
• Métriques online / prod : …
• Seuil go/no-go : …

Déploiement (run)

• Où tourne le modèle (batch, API, edge) : …
• Latence max / SLO : …
• Monitoring en place (qualité, drift, coûts) : …
• Rollback / fallback manuel : …

Coûts

• Coût infra (ordre de grandeur) : …
• Coût annotation / ops : …
• Coût incident (métier) : …

Risques

• SSI / conformité / données perso : …
• Risques produit (hallucinations, biais, erreurs critiques) : …

Si ton sujet touche à la bascule POC vers run, tu peux aussi t’appuyer sur une checklist plus large côté DSI : https://lyon-ia.com/blog/industrialiser-lia-en-dsi-a-lyon-1310-la-checklist-poc-vers-run-mlops-couts-risques.

Le lendemain au bureau : transforme la discussion en décisions (pas en compte-rendu)

Tu sors d’une table ronde, tu as des idées plein la tête. Si tu ne cadres pas, tout s’évapore. Plan simple : 90 minutes le lendemain matin.

1) Réécris ton blocage en “problème de décision”

• “On doit choisir : améliorer la qualité par plus de labels, ou réduire le périmètre pour stabiliser la prod.”
• “On doit choisir : rester assisté, ou automatiser avec un seuil et un fallback.”
• “On doit choisir : optimiser coût LLM par caching/routing, ou changer d’architecture.”

2) Produis une page “3 décisions”

Tu fais un doc d’une page. Trois blocs. Point.

• Données : décision, owner, date, métrique de succès.
• Modèle : décision, seuil, protocole d’éval, risque accepté.
• Run : logging, monitoring, rollback, astreinte ou process incident.

3) Déclenche un test court (7 à 14 jours)

Pas un projet de 3 mois. Un test qui tranche.

• Un jeu de tests figé + une mesure weekly.
• Un shadow mode (le modèle tourne, mais n’impacte pas) pour comparer.
• Un A/B si tu peux, sinon un avant/après propre.

4) Reviens au meetup suivant avec un REX

La série de tables rondes est récurrente. Utilise ça comme une boucle : diagnostic collectif, test court, retour avec résultats, nouvel arbitrage. C’est comme ça que tu avances sans t’enfermer.

Ce que tu dois apporter (et ce que tu dois laisser au placard)

À apporter

• Ton canevas rempli (même à moitié).
• Un chiffre de prod (latence, erreurs, coût, adoption) et une date de bascule.
• Deux options déjà envisagées (A/B), même imparfaites.
• Une question de décision.

À laisser

• Le comparatif d’outils “par principe”.
• Le débat “quel modèle est le meilleur” sans contexte métier.
• Les détails sensibles (tu anonymises, tu changes les noms, tu donnes des ordres de grandeur).

Résumé actionnable

Si tu veux tirer un vrai ROI de cette table ronde data IA Lyon au TUBÀ, fais simple :

• Avant : 1 symptôme + 1 métrique + 1 contrainte, et le canevas copié-collé dans tes notes.
• Pendant : 1 question de décision, et tu forces le groupe à trancher données vs modèle vs run.
• Après : une page “3 décisions” + un test court de 7 à 14 jours, avec owner et métrique.

Tu viens avec un blocage IA. Tu repars avec trois décisions. Et surtout, tu repars avec une façon de les exécuter.

Source événement : page Meetup “Data & IA à Lyon : projets, blocages et retours terrain, Table ronde” (Lyon Data Science, TUBÀ, 17/11/2026, 18h30-20h00, 25 places, format sans slides).