Ce que les tables rondes Lyon Data Science font remonter, sans filtre
À Lyon, les tables rondes type Lyon Data Science servent à une chose simple : confronter des projets IA en entreprise au réel. Pas à des démos. Pas à des slogans. Des gens viennent avec un cas, une contrainte, un blocage. Et ils repartent rarement avec “une meilleure idée”. Ils repartent avec une décision à prendre, souvent inconfortable.
Le signal local est solide. Lyon Data Science est structuré comme une communauté (association) et anime des échanges sur Meetup, Discord et LinkedIn (lyondatascience.org). Le groupe Meetup “Lyon Data Club”, rattaché à la communauté, affiche 1 124 membres (au moment du crawl) et liste des formats orientés retours d’expérience, dont une table ronde “IA frugale” le 9 juin 2026 au TUBÀ (Lyon 3e) (meetup.com).
Le contexte explique pourquoi les mêmes irritants reviennent. En France, 40 % des TPE/PME déclarent utiliser au moins une solution d’IA en 2026, et 53 % des PME dans ce périmètre (France Num, Baromètre 2026). Les usages les plus cités sont “outillés” (contenus 34 %, chatbots 24 %). Donc ça se diffuse vite. Mais ça arrive souvent avant le cadre (gouvernance, sécurité, MLOps). Et c’est là que ça coince quand tu veux passer du test à l’échelle.
Pourquoi ça bloque autant en 2026, même avec des outils “prêts à l’emploi”
Trois raisons reviennent dans les échanges lyonnais.
- La réalité data est hétérogène : beaucoup de pilotage existe, mais l’outillage reste parfois basique. France Num indique que 76 % des TPE/PME disent exploiter leurs données pour piloter, mais les outils cités montrent un grand écart (tableur 44 %, logiciel d’analyse 19 %, IA 5 %) (France Num).
- Le contexte cyber durcit tout : 39 % des TPE/PME déclarent au moins un incident cyber sur 12 mois, et 53 % des dirigeants citent la crainte de perte de données/piratage (France Num). Forcément, dès qu’on parle GenAI, RAG, données internes, ça freine.
- Le passage “POC vers run” est sous-estimé : tu peux sortir un POC en 2 semaines. Industrialiser proprement, c’est un autre sport. Et c’est exactement le terrain des blocages MLOps.
Les 12 blocages récurrents en projets IA en entreprise (version terrain)
Voici une cartographie “praticiens”, typique de ce qui remonte dans des formats tables rondes à Lyon. Chaque blocage vient avec un levier concret.
1) Cas d’usage mal cadré (problème flou, succès non défini)
Symptôme : “On veut un chatbot interne”, “On veut faire de l’IA sur nos ventes”. Et personne n’est d’accord sur la décision à améliorer.
Fix : écrire un contrat d’usage d’une page : objectif, périmètre, qui utilise, décision assistée vs automatisée, seuils qualité, conditions d’arrêt. Pour une méthode de cadrage, tu peux t’appuyer sur https://lyon-ia.com/blog/cadrer-un-projet-ia-methode.
2) ROI non mesuré ou non attribuable (DAF sceptique)
Symptôme : le projet “semble utile”, mais rien n’est défendable au budget.
Fix : choisir 1 à 2 métriques business attribuables et instrumenter dès le POC (temps gagné par dossier, baisse erreurs, délai de traitement, taux de contact utile). Pour cadrer la mesure : https://lyon-ia.com/blog/mesurer-gain-reel-usage-ia et https://lyon-ia.com/blog/mesurer-la-valeur-de-ses-projets-ia-sortir-du-flou-en-2026.
3) Accès aux données lent (droits, silos, dépendances IT)
Symptôme : 3 semaines pour avoir un export. Ou un “non” par défaut car personne ne veut porter le risque.
Fix : sponsor DSI + data owner métier. Processus standard d’habilitation. Catalogue minimal des sources et qui valide quoi. C’est le début de la gouvernance data Lyon au sens opérationnel, pas théorique.
4) Qualité de données insuffisante (manquants, référentiels instables)
Symptôme : le modèle “marche” en notebook, s’effondre avec des données réelles. Doublons, libellés incohérents, changements de règles métiers non documentés.
Fix : arrêter le “grand nettoyage” sans fin. Passer en mode règles de qualité versionnées + monitoring (completude, fraîcheur, unicité, cohérence). Traiter le top 20 % des règles qui détruisent 80 % de la valeur.
5) Gouvernance floue (qui décide, qui porte le risque, qui paie)
Symptôme : un projet data est “à tout le monde” donc à personne. Les arbitrages s’éternisent (cloud, sécurité, budget, priorités).
Fix : un RACI explicite sur tout le cycle de vie (métier, DSI, data, RSSI, DPO, DAF). Pour un angle gouvernance pragmatique : https://lyon-ia.com/blog/gouvernance-ia-entreprise.
6) Blocages MLOps (mise en prod, CI/CD, tests, drift, rollback)
Symptôme : POC validé… puis “on verra plus tard”. Pas de pipeline, pas de versioning, pas de monitoring, pas de procédure de retour arrière.
Fix : imposer une checklist POC vers run dès le départ : dataset versionné, modèle versionné, tests, métriques, monitoring, plan de rollback, owner du run. À Lyon IA, tu as une grille dédiée : https://lyon-ia.com/blog/industrialiser-lia-en-dsi-a-lyon-1310-la-checklist-poc-vers-run-mlops-couts-risques.
7) Sécurité et conformité traitées trop tard (RSSI et DPO débarquent à la fin)
Symptôme : usage GenAI branché sur des données internes, sans cadrage. Résultat : blocage brutal, voire arrêt.
Fix : sécurité dès le cadrage : classification des données, règles de partage, journalisation, gestion des accès, conservation. Pour le volet Shadow AI : https://lyon-ia.com/blog/shadow-ai-en-entreprise-detecter-et-cadrer-les-usages-ia-non-autorises-checklist-rssi-lyon. Pour les garde-fous agents : https://lyon-ia.com/blog/agents-ia-10-garde-fous-avant-dautomatiser-en-entreprise-acces-donnees-actions.
8) Données sensibles et souveraineté non tranchées (cloud, localisation, fournisseurs)
Symptôme : discussion sans fin “on peut / on peut pas” sur l’hébergement, les API externes, les clauses contractuelles.
Fix : prendre 7 décisions avant de brancher une GenAI (hébergement, transit, logs, rétention, sous-traitants, etc.). Pour une approche localement ancrée via l’événement Lyon Data Science : https://lyon-ia.com/blog/lyon-data-science-2809-cadrer-la-souverainete-des-donnees-avant-de-lancer-une-ia.
9) Coûts mal anticipés (tokens, infra, licences, run)
Symptôme : budget “API” sous-estimé, puis explosion dès que l’usage décolle. Ou coût du run oublié (monitoring, support, sécurité).
Fix : modéliser les coûts dès le pilote : volumes, pics, erreurs, rejets, latence. Mettre des garde-fous (quotas, cache, routage vers modèles plus petits). Pour comprendre une facture : https://lyon-ia.com/blog/le-cout-du-token-explique-lire-une-facture-dapi-d-ia.
10) “Dernier kilomètre” métier oublié (processus, exception, responsabilité)
Symptôme : le modèle sort une recommandation, mais personne ne sait qui tranche. Les exceptions explosent. Les équipes contournent.
Fix : intégrer l’IA dans un processus : qui reçoit, qui valide, quels cas passent en manuel, comment on trace. Sur la traçabilité : https://lyon-ia.com/blog/tracabilite-decisions-ia.
11) Compétences et disponibilité (personnes clés surbookées)
Symptôme : 1 data scientist isolé, 1 data engineer introuvable, et le métier pas disponible pour itérer.
Fix : une équipe minimum claire (métier owner, data, IT, sécurité). Et une montée en compétence ciblée. Sur la formation socle : https://lyon-ia.com/blog/former-ses-equipes-a-l-ia. Sur le recrutement local : https://lyon-ia.com/blog/recruter-profil-ia-lyon.
12) Conduite du changement bâclée (adoption réelle faible, méfiance, contournements)
Symptôme : outil livré, peu utilisé. Ou utilisé hors cadre (Shadow AI). Ou rejet car “ça prend plus de temps”.
Fix : design d’adoption : pilotes par équipes, formation courte, règles claires, boucle feedback, mesure avant/après. Et une charte d’usage : https://lyon-ia.com/blog/charte-usage-ia-entreprise.
Plan de déblocage en 3 niveaux : quick wins, 60 jours, 6 mois
Le piège classique des projets IA en entreprise : partir sur un “programme” trop lourd, ou rester coincé en POC. Voilà une trajectoire simple, inspirée de ce qui marche quand les équipes reviennent au terrain.
Niveau 1 : quick wins (10 jours ouvrés)
- Contrat d’usage 1 page + décision “go / no go” (blocage 1).
- 2 métriques attribuables + instrumentation minimale (blocage 2).
- RACI du projet, même moche, mais explicite (blocage 5).
- Classification des données du cas d’usage (sensibilité, diffusion) (blocages 7 et 8).
- Jeu de tests de base (50 cas) pour éviter les débats sans fin (blocage 6). Pour une méthode : https://lyon-ia.com/blog/evaluer-reponses-ia-jeu-de-tests.
Niveau 2 : chantiers 60 jours (pour passer du pilote à un “produit interne”)
- Accès aux données standardisé : owner, règles d’habilitation, sources listées (blocage 3).
- Règles de qualité versionnées + monitoring simple (blocage 4).
- Chemin MLOps minimal : versioning, CI/CD, monitoring, rollback (blocage 6).
- Garde-fous sécurité : logs, gestion des accès, conservation, secrets (blocage 7). Sur la conservation : https://lyon-ia.com/blog/politique-conservation-donnees-ia.
- Modèle de coûts (tokens, infra, run) + limites (blocage 9).
Niveau 3 : chantiers 6 mois (pour industrialiser et multiplier les cas)
- Gouvernance data et IA : portefeuille de cas, critères d’arbitrage, comité léger mais régulier (blocages 2 et 5).
- Plateforme : briques réutilisables (auth, observabilité, catalogue, vector store si besoin) au lieu de réinventer à chaque fois (blocage 6).
- Cadre conformité : registre des usages, preuves, contrats, droits (blocage 7). Pour documenter : https://lyon-ia.com/blog/ai-act-documenter-vos-usages-dia-en-entreprise-registre-pret-a-copier-exemple-pme-lyon.
- Conduite du changement industrialisée : formation, réseau d’ambassadeurs, support, mesure d’adoption (blocages 11 et 12).
Grille de diagnostic express (DSI, DAF, métiers) : 18 questions qui évitent les débats stériles
À utiliser avant ou après une table ronde type Lyon Data Science. Tu notes chaque item en vert, orange, rouge. Si tu as 5 rouges, tu n’as pas un “problème IA”. Tu as un problème d’exécution.
Pour la DSI (exécution et run)
- Accès data : délai moyen pour obtenir une source utile, c’est combien ?
- Versioning : dataset et modèle versionnés, oui/non ?
- Tests : jeu de tests reproductible, oui/non ?
- Monitoring : qualité, drift, latence, coûts, oui/non ?
- Rollback : procédure écrite, owner identifié, oui/non ?
- Sécurité : logs, secrets, IAM, séparation environnements, oui/non ?
Pour la DAF (valeur et risque financier)
- ROI : 1 à 2 métriques attribuables définies, oui/non ?
- Baseline : mesure “avant” disponible, oui/non ?
- Coûts : modèle coût complet (build + run) estimé, oui/non ?
- Seuil d’arrêt : critères de stop écrits, oui/non ?
- Priorisation : place du cas d’usage dans le portefeuille, claire, oui/non ?
- Contrats : clauses clés IA et données relues, oui/non ? Pour cadrer : https://lyon-ia.com/blog/contrat-fournisseur-ia-clauses.
Pour les métiers (adoption et impact)
- Décision cible : quelle décision est améliorée, exactement ?
- Responsable : qui tranche quand l’IA se trompe ?
- Exceptions : liste des cas hors scope, définie, oui/non ?
- Process : l’IA est intégrée au workflow, oui/non ?
- Adoption : indicateur d’usage réel défini, oui/non ?
- Charte : règles d’usage claires, oui/non ?
Retombées concrètes à viser après une table ronde (J+7, J+30, J+90)
Si tu sors d’un échange type Lyon Data Science avec “des idées”, tu as raté le point. Tu veux des artefacts. Des décisions. Des owners.
- J+7 : contrat d’usage signé, RACI, métriques, classification des données.
- J+30 : jeu de tests, coût estimé, chemin POC vers run validé, pilote lancé avec instrumentation.
- J+90 : premier usage en production (même petit), monitoring, retour utilisateur, décision d’extension ou d’arrêt.
Si tu veux un format de questions à emmener dans ce type d’événement lyonnais : https://lyon-ia.com/blog/data-ia-a-lyon-1711-tuba-12-questions-pour-debloquer-ton-projet.
Ce que tu peux faire dès maintenant si ton projet est bloqué
Tu prends les 12 blocages ci-dessus. Tu coches ceux qui te concernent. Ensuite tu fais simple :
- Si tu es DSI : impose la checklist MLOps minimale (tests, versioning, monitoring, rollback). Sans ça, tu empiles des POC.
- Si tu es DAF : exige 2 métriques attribuables et un seuil d’arrêt. Sans ça, tu finances un débat.
- Si tu es métier : clarifie la décision cible, le responsable, et comment on traite les exceptions. Sans ça, tu n’auras pas d’adoption.
Et si tu veux l’approche “retour terrain” en format court, alignée avec l’esprit des tables rondes : https://lyon-ia.com/blog/table-ronde-lyon-data-science-0610-debloque-ton-projet-ia-en-90-minutes.
Sources
- Lyon Data Science, contact et canaux communauté : https://lyondatascience.org/contact/
- Meetup Lyon Data Club (membres, événements dont table ronde IA frugale au TUBÀ) : https://www.meetup.com/fr-fr/lyondataclub/
- Baromètre France Num 2026 (adoption IA, usages, cybersécurité, pilotage par la donnée) : https://www.francenum.gouv.fr/guides-et-conseils/strategie-numerique/comprendre-le-numerique/barometre-france-num-2026-le
Laisser un commentaire