Lyon Data Science (06/10) : viens avec un blocage IA, repars avec une décision

Tu bloques sur ton IA. Tu n’as pas besoin d’une conf. Tu as besoin d’un arbitrage.

Un POC qui tourne mais personne ne signe le passage en prod. Un RAG qui répond bien lundi et n’importe quoi jeudi. Des coûts LLM qui montent sans que personne ne sache pourquoi. Un MLOps “à la main” qui fatigue l’équipe. Une gouvernance floue qui empêche d’ouvrir l’accès aux bonnes données.

Ce type de blocage, tu ne le débloques pas avec une énième slide. Tu le débloques en posant le problème proprement, en le découpant, puis en repartant avec une décision nette.

C’est l’idée de la table ronde IA Lyon organisée par la communauté Lyon Data Science au TUBÀ Lyon : une rencontre participative, en petit groupe, où les sujets viennent des participants et où l’objectif est le retour terrain.

Infos pratiques, vérifiables (et utiles)

• Intitulé : Data & IA : projets, blocages et retours terrain, Table ronde (source : Meetup)
• Date : mardi 6 octobre 2026
• Horaire : 18h30 à 20h00 (CEST)
• Lieu : TUBÀ Lyon, Lyon Part-Dieu, Place Charles Béraudier, 69003 Lyon
• Format : rencontre participative en petit groupe, orientée problèmes concrets et retours d’expérience
• Capacité : 25 personnes
• À préparer : pas de longue conférence, pas de slides
• Sujets : proposés sur place ou en amont via commentaires Meetup ou Discord
• Langue : surtout français, interventions en anglais bienvenues

Pour le contexte local : Lyon Data Science se présente comme une communauté/association qui démocratise la data science, l’IA et le ML avec des événements gratuits, et son groupe Meetup annonce environ 4 600 membres (source : Meetup, site Lyon Data Science).

Pour un aperçu “viens avec un blocage, repars avec un plan”, tu peux aussi lire : https://lyon-ia.com/blog/table-ronde-lyon-data-science-x-tuba-0610-viens-avec-un-blocage-repars-avec-un-plan.

À qui ça sert vraiment (et à qui ça sert moins)

Tu devrais venir si

• Tu portes un projet data/IA en entreprise à Lyon ou en AURA, et tu as un point dur précis.
• Tu es data scientist, data engineer, ML engineer, dev, architecte, produit, RSSI, DPO… et tu veux un retour d’expérience IA sans filtre.
• Tu es freelance, étudiant, en reconversion, entrepreneur, mais tu as un cas concret (même modeste) et tu veux comprendre quoi décider ensuite.

Ça risque de te frustrer si

• Tu veux une conf magistrale avec un “top 10 des outils”.
• Tu cherches une validation vague du type “l’IA c’est l’avenir”.
• Tu viens sans contexte, sans chiffres, et sans contrainte. Dans ce cas, le groupe ne peut pas trancher.

Le format : ce que tu vas vivre sur place

Ce qui est annoncé, c’est simple : petit groupe, participatif, problèmes concrets, retours terrain. Donc attends-toi à :

• Des sujets proposés par les participants (sur place ou en amont).
• Des discussions orientées “qu’est-ce qui coince, pourquoi, et qu’est-ce qu’on décide”.
• Des arbitrages d’architecture (build vs buy, RAG vs fine-tuning, cloud vs local, etc.).
• Des questions run : MLOps, observabilité, sécurité, gouvernance, coûts.

Le bon état d’esprit : tu ne viens pas “pitcher” ton projet. Tu viens le mettre à l’épreuve pour sortir du flou.

Quels blocages sont “acceptés” (et même recherchés)

Le titre annonce “projets, blocages et retours terrain”. Donc oui, les sujets qui fâchent passent très bien. Voilà des exemples typiques, très compatibles avec une table ronde utile.

1) Architecture : tu as un cas d’usage, mais pas de design défendable

• Où placer le RAG : côté app, côté data platform, côté outil support ?
• Comment isoler les données sensibles ?
• Comment gérer le multi-tenant (équipes, filiales, clients) ?
• Comment éviter un “chatbot universel” ingouvernable ?

Objectif sur place : repartir avec une architecture cible minimaliste et une liste d’arbitrages à faire (et par qui).

2) RAG : ça marche en démo, puis ça dérive

Le RAG, c’est souvent là que les équipes se font surprendre. En 2025-2026, beaucoup de travaux insistent sur un point : il faut séparer les problèmes de retrieval (récupération) des problèmes de generation (réponse), et définir des métriques adaptées au contexte réel, pas juste un benchmark générique (source : article Springer sur l’évaluation RAG).

• Le moteur récupère les mauvais passages (chunking, embeddings, filtres, metadata).
• La base documentaire change et personne ne contrôle la qualité.
• Les réponses “sonnent juste” mais sont fausses ou non sourcées.
• Les utilisateurs n’écrivent pas leurs questions comme en test.

Objectif sur place : repartir avec un plan de test (jeu de questions, critères, seuils d’acceptation) et une décision : corriger le retrieval, changer le prompting, revoir les documents, ou arrêter le cas d’usage.

À relire si tu veux remettre le RAG à plat avant de venir : https://lyon-ia.com/blog/rag-ia-documents-entreprise et https://lyon-ia.com/blog/fine-tuning-ou-rag.

3) Coûts LLM : ton budget explose alors que “les tokens baissent”

Classique. Le coût réel ne vient pas seulement du prix API. Il vient aussi de la consommation de tokens, des retries, de l’infra, de l’observabilité et du contrôle humain (source : TechRadar). Des analyses pointent aussi une baisse de coûts d’inférence sur la durée, mais un écart persistant entre prix affiché et coût réel en production (source : McKinsey).

• Prompts trop longs, contexte surchargé, documents mal découpés.
• Pas de limites par équipe, pas de quota, pas de mesure par cas d’usage.
• Latence qui déclenche des retries, et double la facture.
• Pas de stratégie modèle : tout part sur le plus gros modèle “au cas où”.

Objectif sur place : repartir avec une décision simple du type budget par cas d’usage, règles de routage (petit modèle vs gros), observabilité tokens, et un plan d’optimisation en 2 semaines.

Pour cadrer tes chiffres : https://lyon-ia.com/blog/le-cout-du-token-explique-lire-une-facture-d-api-d-ia et https://lyon-ia.com/blog/baisse-du-prix-des-tokens-pourquoi-votre-budget-ia-va-quand-meme-exploser.

4) Industrialisation MLOps : tu as un modèle, pas un système

• Déploiement manuel, pas de CI/CD, pas de rollback.
• Pas de versioning des datasets, pas de traçabilité d’expériences.
• Monitoring faible : tu découvres les problèmes via les utilisateurs.
• Personne ne sait qui est on-call quand “l’IA déconne”.

Objectif sur place : repartir avec un chemin POC vers run et des responsabilités claires (DSI, data, sécurité, métier).

Si tu veux venir avec une checklist déjà structurée : https://lyon-ia.com/blog/industrialiser-lia-en-dsi-a-lyon-1310-la-checklist-poc-vers-run-mlops-couts-risques.

5) Gouvernance : tu peux faire un POC, mais tu ne peux pas ouvrir l’usage

La gouvernance, ce n’est pas un comité de plus. C’est “qui a le droit de faire quoi”, “avec quelles données”, “avec quel niveau de preuve”, “et comment on audite”. En UE, la Commission européenne rappelle un calendrier d’applicabilité progressif de l’AI Act, avec notamment des obligations d’AI literacy depuis le 2 février 2025 et des obligations liées aux modèles GPAI applicables depuis le 2 août 2025, et d’autres exigences de transparence mentionnées pour 2026 (source : Commission européenne).

• Accès aux données : pas de RBAC/ABAC propre, pas de séparation environnements.
• Données perso et sensibles : personne ne sait ce qui peut sortir, ni comment.
• Shadow AI : les équipes utilisent des outils non déclarés.
• Traçabilité : impossible de reconstruire pourquoi une décision a été prise.

Objectif sur place : repartir avec une décision “gouvernance minimale viable” : règles d’accès, registre des usages, logs, et un processus d’approbation léger.

Pour poser un cadre avant de venir : https://lyon-ia.com/blog/gouvernance-ia-entreprise, https://lyon-ia.com/blog/shadow-ai-en-entreprise, https://lyon-ia.com/blog/ai-act-documenter-vos-usages-dia-en-entreprise-registre-pret-a-copier-exemple-pme-lyon, https://lyon-ia.com/blog/tracabilite-decisions-ia.

Le canevas 1 page à préparer avant de venir (copie-colle)

Tu veux un retour utile en 15 minutes de discussion. Prépare ça. Une page. Pas plus. Si tu arrives avec ça, tu repars presque forcément avec une décision.

1) Contexte et objectif
Produit / service concerné :
Utilisateurs cibles (qui, combien, à quelle fréquence) :
Décision à obtenir après la table ronde (choix d’archi, budget, go/no-go, plan 30 jours) :

2) Cas d’usage exact
Entrée : (question utilisateur, document, ticket, image, audio, etc.)
Sortie attendue : (réponse sourcée, action, classification, extraction, résumé, etc.)
Ce que l’IA a le droit de faire, et ce qu’elle n’a pas le droit de faire :

3) Données
Sources : (SharePoint, Drive, ERP, CRM, base SQL, wiki, mails, PDF, etc.)
Volumétrie : (nb docs, taille, fréquence de mise à jour)
Qualité : (doublons, versions, docs obsolètes, structure, langue)
Sensibilité : (données perso, secrets industriels, contrats, RH, santé, etc.) :

4) Contraintes SI et sécu
Où ça doit tourner : (cloud public, cloud souverain, on-prem, hybride)
Identité et accès : (SSO, MFA, RBAC, comptes de service)
Traçabilité : (logs, audit, conservation)
Intégrations : (API, réseau, proxy, restrictions) :

5) Architecture actuelle
Modèle(s) : (API, open source, local)
RAG : (oui/non, vecteur, chunking, filtres, reranking)
Orchestration : (outil, code maison, workflows)
Monitoring : (latence, coûts tokens, qualité réponses, feedback) :

6) Risques et garde-fous
Top 3 risques : (hallucination, fuite, biais, conformité, sécurité, réputation)
Mesures déjà en place : (red teaming, filtres, modération, anonymisation, HITL) :

7) Mesures de succès
Métriques métier : (temps gagné, taux de résolution, conversion, etc.)
Métriques qualité : (exactitude, citations, taux “je ne sais pas”, satisfaction)
Seuils d’acceptation pour passer en prod :
Budget cible : (euros/mois, tokens/mois, coût par interaction) :

8) Le blocage en une phrase
“On n’arrive pas à … parce que …, et on a besoin de décider entre … et …”

Exemples de blocages typiques à apporter (prêts à formuler)

• RAG qui dérive : “La recherche ramène des docs OK, mais les réponses changent d’une semaine à l’autre. On ne sait pas si c’est les documents, l’index, ou le prompt. On veut décider quoi instrumenter et quel test minimal mettre en place.”
• Coûts LLM : “Le coût par ticket support est passé de X à Y en 2 mois. On veut décider une politique de contexte, de routage modèles, et un budget plafond par équipe.”
• Industrialisation MLOps : “Le modèle est bon, mais le run est fragile. On veut décider l’ordre des chantiers : CI/CD, monitoring, data drift, ou gouvernance des releases.”
• Gouvernance des accès : “On veut ouvrir l’outil à 300 personnes, mais on n’a pas de règles d’accès aux docs, ni de journalisation. On veut décider le socle minimal de sécurité et de traçabilité.”

Ce que tu dois viser en sortant : une décision, pas une idée

Une table ronde utile se termine par un truc clair. Par exemple :

• Décision d’architecture : “On part sur un RAG avec filtrage metadata par entité + citations obligatoires, pas de fine-tuning pour l’instant.”
• Décision d’industrialisation : “On met en place logging et évaluation automatique avant d’ajouter des features.”
• Décision gouvernance : “Accès via SSO, comptes de service dédiés, registre des usages, et règle de conservation des logs.”
• Décision budgétaire : “On fixe un coût max par interaction, et on route 80 % des requêtes sur un modèle plus petit.”

Si tu veux t’entraîner à raconter ton retour d’expérience IA de façon “décisionnable”, cette autre rencontre lyonnaise est dans la même veine : https://lyon-ia.com/blog/lyon-dsi-club-1310-prepare-ton-rex-ia-pour-obtenir-une-decision-pas-des-idees.

Plan d’attaque en 30 minutes avant le 06/10

• 10 min : remplis le canevas 1 page ci-dessus, sans chercher la perfection.
• 10 min : choisis 3 métriques. Une métrique métier, une métrique qualité, une métrique coût.
• 10 min : écris ton blocage en une phrase + deux options d’arbitrage (A vs B).

Tu arriveras avec un sujet “discutable”. Donc tranchable. Donc utile.

Sources

• Page Meetup de l’événement “Data & IA : projets, blocages et retours terrain, Table ronde” (date, heure, lieu, format, capacité, langue, modalités sujets).
• Site Lyon Data Science (présentation communauté/association, événements gratuits).
• Évaluation RAG : article Springer (2026) sur les cadres et métriques distinguant retrieval et generation.
• Coûts réels IA : TechRadar (token, retries, infra, observabilité, humain) ; McKinsey (agentic economics, écart prix affiché vs coût réel).
• Calendrier AI Act côté Commission européenne (AI literacy, GPAI, transparence).
• NIST AI RMF et profil Generative AI (NIST.AI.600-1, 2024) comme cadre opérationnel de gestion des risques.

Ce que tu peux faire maintenant

Choisis ton blocage. Écris-le en une phrase. Remplis le canevas 1 page. Et viens chercher un arbitrage sur architecture, RAG, MLOps, gouvernance. C’est exactement le type de discussion que la communauté Lyon Data Science met sur la table à Lyon, en format court, sans slides, et orienté retour d’expérience IA.