Meetup Mindstone Lyon (18/11) : repars avec un workflow LLM utile (et mesurable) en 2 semaines

Tu veux du concret, pas une démo LinkedIn

Un meetup IA Lyon, ça peut être deux heures sympas et… zéro impact lundi matin. Ou l’inverse : une idée simple, cadrée, testable, qui devient un workflow LLM entreprise réellement utile en 2 semaines.

Le Mindstone Lyon November AI Meetup annonce clairement la couleur : “Practical AI”, avec 3 talks (un talk technique “building with LLMs”, une démo productivité, un talk prospectif) puis pizza, drinks & networking. L’objectif réaliste, ce n’est pas de repartir avec “un projet IA”. C’est de repartir avec une piste exploitable et une méthode pour la tester proprement.

Infos vérifiables : date, lieu, format, capacité

• Événement : Mindstone Lyon November AI Meetup (Mindstone Lyon)
• Date : mardi 18 novembre 2026
• Heure : ouverture 18:00 (doors open, puis talks, puis networking)
• Lieu : Epitech, 2 Rue du Professeur Charles Appleton, 69007 Lyon
• Prix : gratuit
• Capacité : 200 places (limitées)
• Organisation : Harry Bloom (organiser indiqué sur la page Mindstone)

Source principale : community.mindstone.com. Le groupe local “Mindstone Lyon AI Meetup” est aussi référencé sur Meetup : meetup.com. L’événement circule aussi sur un agenda tiers : acqeo.com.

Qui y gagne vraiment (et pourquoi)

Ce meetup va surtout servir à celles et ceux qui viennent avec un problème réel et une contrainte réelle (données, validation, sécurité, intégration). Pas à ceux qui cherchent “le meilleur prompt universel”.

Product managers et responsables produit

Tu viens avec un irritant utilisateur. Tu repars avec un cadrage testable : job-to-be-done, critères de succès, décision go/no-go.

• Cas typiques : support, rédaction interne, sales enablement, recherche documentaire.
• Ce que tu dois viser : une première version utilisable sur un périmètre étroit.

Développeurs, data, ML engineers

Tu viens avec une contrainte d’intégration. Tu repars avec un squelette de workflow : prompting structuré, RAG léger si besoin, et surtout une idée d’évaluation.

• Ce que tu gagnes : éviter le piège “ça marche en démo, ça casse en prod”.
• Ce que tu dois apporter : un pipeline minimal, pas une architecture cathédrale.

Ops, RevOps, responsables support

Tu viens avec du volume, des SLA, des irritants, des métriques. Tu repars avec une approche avant/après qui parle au business.

• Cas typiques : tri de tickets, pré-réponses, résumés, routage, QA.
• Métriques faciles : temps de traitement, taux de réouverture, taux de retouche.

Consultants et freelances (SI, data, orga)

Tu viens avec un cas client petit mais fréquent. Tu repars avec une trame de pilote en 2 semaines, avec livrables et garde-fous.

• Ce que tu vends ensuite : une exécution cadrée, pas “de l’IA”.
• Ce que tu dois éviter : promettre une transformation complète en 15 jours.

Les meilleurs sujets à apporter (ceux qui passent en 2 semaines)

Si ton idée demande 6 mois de data engineering, laisse tomber pour l’instant. Pour ressortir avec un workflow LLM entreprise testable, privilégie :

• forte répétition (beaucoup d’occurrences chaque semaine)
• faible ambiguïté (on sait reconnaître une bonne réponse)
• avant/après mesurable (temps, qualité, risques)

Support

• Tri et catégorisation de tickets
• Résumé de ticket pour escalade N2
• Pré-réponse + reformulation au ton maison
• Suggestion d’articles de base de connaissances

Mesure simple : minutes gagnées par ticket, et taux de retouche par un humain.

Rédaction

• Compte rendu de réunion à partir de notes
• Fiche produit standardisée
• Proposition commerciale sur un gabarit
• Emails internes “toujours pareils”

Mesure simple : temps gagné + checklist qualité (structure, ton, conformité, exactitude).

Sales enablement

• Synthèse de compte à partir de notes CRM
• Réponses à objections à partir d’un playbook
• Préparation d’emails personnalisés à partir d’un brief

Mesure simple : temps gagné par commercial, et cohérence avec le playbook (score interne).

Analyse documentaire

• Recherche dans procédures, wiki, docs techniques
• Extraction de clauses, points clés, obligations
• Comparaison de versions, synthèses ciblées

Ici, le RAG léger devient souvent utile, mais uniquement si la valeur vient de tes documents (pas de la “connaissance générale” du modèle).

Transformer un talk ou une démo en workflow testable

Le piège classique en meetup : tu notes 25 idées, tu ne fais rien. Méthode plus rude, plus efficace : pendant chaque talk, note uniquement 3 items.

• Le problème visé : quelle tâche, pour quel utilisateur, à quelle fréquence ?
• Le mécanisme : LLM + prompt ? RAG ? outil d’orchestration ? validation humaine ?
• La mesure : comment ils savent que “ça marche” (temps, qualité, risques) ?

À la fin du meetup, tu dois être capable de formuler une phrase : “Je peux tester ça sur 20 exemples d’ici vendredi.”

Mini-guide : repartir avec un workflow LLM mesurable en 2 semaines

Objectif : un pilote court, cadré, mesuré. Pas un chantier illimité. Voici une trame simple que tu peux suivre dès maintenant, avant de venir au Mindstone Lyon.

1) Définis un job-to-be-done ultra concret

Formule : “Quand je dois …, je veux …, afin de …”

Exemples (bons) :

• “Quand je reçois un ticket support, je veux un résumé + une proposition de réponse, afin de traiter 30% plus vite sans dégrader la qualité.”
• “Quand je dois rédiger une fiche produit, je veux un draft au bon format, afin de réduire le temps de rédaction et garder un ton homogène.”

Ce que tu apportes au meetup : 3 phrases max + contexte (outil actuel, qui valide, délai attendu, données dispo).

2) Prépare ton mini jeu d’exemples (10 à 30)

Sans exemples, tu ne testeras rien. Tu feras du théâtre.

• Vise 10 à 30 exemples réels (anonymisés) : tickets, emails, paragraphes, extraits de docs.
• Pour chaque exemple, prépare :
• Entrée (le contenu brut)
• Sortie attendue (ce que tu considères “ok”)
• Critères d’acceptation (1 à 2, pas 15)

Si tu veux creuser la partie test, tu peux t’appuyer sur ce guide Lyon IA : https://lyon-ia.com/blog/evaluer-reponses-ia-jeu-de-tests.

3) Choisis “simple d’abord” côté outils

But : livrer un flux qui tourne, pas optimiser au dixième.

• Niveau 0 : LLM + prompt structuré. Souvent suffisant pour synthèse, classification, rédaction.
• Niveau 1 : RAG léger si et seulement si la valeur vient de tes documents internes.

Check-list pratique avant de partir sur du RAG :

• Où sont les documents ? (wiki, Drive, PDF, SharePoint…)
• Qui a le droit d’y accéder ?
• Quels formats posent problème ? (scans, tableaux, versions multiples)

Pour poser les bases : https://lyon-ia.com/blog/rag-ia-documents-entreprise et https://lyon-ia.com/blog/assistant-interne-documentation-entreprise.

4) Mesure. Sinon ce n’est pas un workflow, c’est une démo

Tu mesures sur un échantillon. Pas sur une intuition.

Temps gagné

• Mesure avant : combien de minutes pour faire la tâche sans IA sur 10 cas.
• Mesure après : combien de minutes avec IA + retouches.
• Calcule : minutes économisées par tâche x volume hebdo.

Méthode détaillée ici : https://lyon-ia.com/blog/mesurer-gain-reel-usage-ia.

Qualité

• Taux de retouche (combien de modifications avant validation)
• Score interne 1 à 5 par relecteur
• Conformité à une checklist (format, exactitude, ton, sources)

Astuce : impose une sortie structurée (JSON ou sections fixes). Tu gagnes en contrôlabilité.

Risques

• Erreurs factuelles et hallucinations
• Fuite de données (copier-coller, logs, prompts)
• Ton de marque et conformité (juridique, réglementaire)
• Biais et réponses “trop sûres d’elles”

Prépare 5 cas pièges (données manquantes, contradiction, doc obsolète, question mal posée…). Si ton workflow passe ces 5 cas, tu as un début de robustesse.

Pour la partie sécurité, garde en tête l’injection de prompt : https://lyon-ia.com/blog/injection-de-prompt-securite.

5) Décide go/no-go avec des seuils définis avant le test

Tu fixes des seuils, puis tu suis le résultat. Pas l’inverse.

• Go si tu atteins ton seuil (exemple : temps -30% ET retouches < X ET 0 incident sur cas pièges “rouges”).
• No-go si le gain n’est pas stable ou si le risque domine.

Et si c’est no-go, tu ne “jettes pas”. Tu notes ce qui bloque :

• données (qualité, accès, format)
• validation (qui signe, quand, sur quels critères)
• intégration (où ça doit vivre : CRM, helpdesk, intranet)
• gouvernance (droits, logs, conservation, traçabilité)

Plan d’attaque sur 2 semaines (simple et réaliste)

Tu viens au meetup pour accélérer, pas pour réfléchir à zéro. Voici un plan court.

Avant le meetup (J-7 à J-1)

• Choisis 1 cas d’usage (pas 3).
• Écris ton JTBD (1 minute à lire).
• Prépare 10 à 30 exemples anonymisés.
• Définis 3 métriques : temps, qualité, risque.

Soir du meetup (J0)

• Note les 3 items par talk (problème, mécanisme, mesure).
• En networking : teste ton JTBD sur 2 personnes. Si elles ne comprennent pas en 30 secondes, c’est trop flou.
• Repars avec une action écrite : “Vendredi, je teste sur 20 cas.”

Semaine 1 (J+1 à J+7)

• Prototype niveau 0 : prompt structuré + format de sortie imposé.
• Teste sur 10 cas, ajuste uniquement ce qui casse souvent.
• Ajoute un contrôle humain clair : qui valide quoi.

Semaine 2 (J+8 à J+14)

• Monte à 20 à 30 cas, dont 5 cas pièges.
• Mesure avant/après, collecte le score qualité.
• Décision go/no-go + prochaine étape (industrialisation ou arrêt net).

Ce que tu dois apporter physiquement (oui, vraiment)

• Ton JTBD imprimé ou dans Notes (3 phrases).
• Une description de ton flux actuel (3 étapes max).
• 10 à 30 exemples anonymisés prêts à tester.
• 3 métriques et tes seuils go/no-go.

Si tu viens sans exemples et sans métriques, tu repartiras avec… des idées.

Pour rester dans le “practical” et éviter le POC vitrine

Si tu veux une autre checklist orientée intégration “practical”, ce papier Lyon IA peut t’aider à cadrer tes questions avant le meetup : https://lyon-ia.com/blog/mindstone-lyon-1811-8-questions-pour-integrer-lia-practical-pas-un-poc-vitrine.

Ce que tu peux décider dès maintenant

Si tu vises la productivité IA Lyon côté entreprise, prends 15 minutes et fais ça :

• Choisis un seul sujet parmi support, rédaction, sales enablement, analyse documentaire.
• Écris ton JTBD (quand, je veux, afin de).
• Prépare 15 exemples anonymisés.
• Fixe un seuil simple : “si je ne gagne pas 30% de temps sans baisse qualité, j’arrête”.

Le 18/11, tu n’iras pas “voir des talks”. Tu iras récupérer ce qu’il te manque pour transformer l’idée en workflow testable. Et deux semaines plus tard, tu sauras si ça vaut le coup, chiffres à l’appui.