CHU HealthTech Connexion Day #5 à Lyon : préparer une collab CHU IA sans se griller

Un CHU ne “teste pas une IA”, il accepte de prendre un risque

Tu viens au CHU x HealthTech Connexion Day #5 avec une startup d’IA en santé. Tu penses “POC rapide”. Le CHU pense “patients, responsabilités, conformité, sécurité, charge équipe, réputation”. Si tu arrives avec un pitch produit et deux screenshots, tu perds la salle en 5 minutes. Pire, tu te grilles pour six mois.

La bonne approche est simple, mais exigeante : tu te présentes comme un partenaire qui comprend le terrain hospitalier, ses contraintes et sa façon de décider. Et tu repars avec un prochain pas clair, pas avec une promesse floue.

Rappel factuel : HealthTech Connexion Day Lyon, format et écosystème

La 5e édition du CHU x HealthTech Connexion Day est annoncée à Lyon, au Centre des congrès (Cité internationale), les 1er et 2 décembre 2026. C’est une formule sur 1 jour et demi, avec une plateforme digitale pour préparer et prolonger les échanges.

Côté hospitalier, l’édition lyonnaise est annoncée comme organisée par le GCS Houraa, qui regroupe 4 CHU de la région : Lyon, Grenoble, Saint-Étienne, Clermont-Ferrand. L’événement est porté par France Biotech et la Conférence des Directeurs Généraux de CHU/CHRU. Les organisateurs communiquent sur un ordre de grandeur 1200+ participants, 140+ intervenants, 120+ exposants, et la précédente édition est annoncée à 1 200 participants, 120 intervenants, 120 exposants.

Pourquoi ça compte pour toi, startup IA santé Lyon (ou AURA) ? Parce que ce type d’événement n’est pas un salon. C’est une porte d’entrée structurée vers des décideurs et des “faiseurs” CHU. À condition de parler leur langage opérationnel.

À quoi sert vraiment un événement CHU-startups (et ce que le CHU attend)

1) Accéder au terrain, sans brûler les étapes

Un CHU n’achète pas une “IA”. Il adopte un usage clinique dans un parcours avec des contraintes :

• Qui porte l’usage côté hôpital (clinique, DSI, DPO, biomédical, qualité, direction de la recherche, achats) ?
• Où s’insère l’outil (consultation, imagerie, bloc, urgences, hospitalisation, RCP, pharmacie, etc.) ?
• Qu’est-ce qui change (décision, délai, triage, priorisation, réduction d’événements indésirables, charge de saisie) ?

La HAS structure l’évaluation des technologies numériques et systèmes d’IA à usage professionnel selon le statut (DM ou non), le contexte d’usage et le cycle de vie. Traduction : si tu n’as pas cadré ton usage, tu ne peux pas être évalué proprement.

2) Mettre sur la table, tout de suite, les contraintes clinique et réglementaire

Le piège classique : “On fera la conformité si le pilote marche.” Mauvais ordre. Si ta solution est, ou devient, un dispositif médical numérique, tu dois anticiper trajectoire de conformité, sécurité, gestion des risques, gestion des changements. Les ressources G_NIUS sur le marquage CE et la mise en place d’un SMQ donnent un point d’entrée concret.

3) Comprendre que sécurité et interopérabilité sont des tickets d’entrée

Dans le numérique en santé français, la doctrine du numérique en santé met l’accent sur interopérabilité, sécurité, éthique et briques de confiance (par exemple Pro Santé Connect pour l’authentification). Si tu ne sais pas répondre sur ces points, tu es “non déployable” par défaut, même si ton modèle est brillant.

La check-list “anti-grillage” avant HealthTech Connexion Day Lyon

Objectif : arriver avec un dossier court, concret, et testable. Tu veux faciliter le travail du clinicien référent et éviter de déclencher le réflexe “risque + surcharge = non”.

Bloc 1 : preuve de valeur, cas clinique, et plan d’évaluation (pas une démo)

Tu dois être capable d’expliquer ton produit comme une hypothèse clinique qu’on va vérifier, pas comme une feature.

• Un seul problème prioritaire. Pas trois spécialités, pas dix fonctionnalités.
• Population : qui est concerné, inclusion, exclusion, volume mensuel réaliste.
• Comparateur : “soins usuels” ou une méthode existante. Sans comparateur, pas de résultat interprétable.
• Critère principal : celui qui fera dire “on continue” ou “on arrête”.
• Critères secondaires : temps gagné, réduction de retours, satisfaction, délai de prise en charge.
• Horizon temporel : 4 semaines, 3 mois, 6 mois. Assume. Explique pourquoi.
• Impact organisationnel : qui clique, qui valide, qui corrige, combien de minutes.

La HAS rappelle que la structuration d’une démarche d’évaluation dépend fortement du statut et du contexte d’usage. Donc tu arrives avec un mini-protocole réaliste terrain, pas un PDF “étude clinique” copié-collé.

Erreur qui tue : “On veut juste accéder aux données et on verra.” Non. Tu dois dire “voilà l’évaluation qu’on peut faire avec un effort raisonnable pour votre équipe”.

Bloc 2 : données de santé, base légale, hébergement, traçabilité

Si tu touches des données de santé, tu dois être carré avant de demander quoi que ce soit. Arrive avec un schéma simple et lisible.

• Liste des données : variables nécessaires, sources (DPI, imagerie, labo), format, fréquence.
• Finalité : entraînement, ajustement, inférence, monitoring. Pas de mélange flou.
• Où transitent les données : poste, serveur CHU, cloud, API, journaux.
• Qui accède : équipe CHU, ton équipe, sous-traitants éventuels.
• Durée de conservation : par type de donnée, et pourquoi.
• Hébergement : si tu héberges des données de santé sur support électronique, anticipe l’exigence d’un hébergeur certifié HDS (références CNIL, notamment autour du DPI).
• Traçabilité en routine : comment on sait qu’une IA a été utilisée, quand, par qui, sur quel dossier. Le guide HAS-CNIL sur l’IA en contexte de soins insiste sur l’intégration de la traçabilité dans les processus qualité.

Erreur qui tue : arriver avec “On anonymise” sans être capable d’expliquer comment, et surtout ce que tu appelles anonymisation (souvent, c’est de la pseudonymisation). Tu vas déclencher un stop immédiat côté DPO.

Bloc 3 : éthique, responsabilités, et contrôle humain (human in the loop)

Tu dois clarifier le modèle de responsabilité. Pas pour faire plaisir. Parce que personne ne signera un pilote si c’est flou.

• Rôles RGPD : responsable de traitement, sous-traitant, coresponsables. Mets une proposition, même si elle sera ajustée.
• Contrôle humain : qui valide la sortie IA, à quel moment, selon quel protocole. Et surtout, que se passe-t-il en cas de désaccord entre l’IA et le clinicien.
• Biais et performance : ce que tu as déjà mesuré (par site, par machine, par population), et ce que tu proposes de mesurer en pilote.
• Information et transparence : ce que tu peux expliquer sur le modèle, ses limites, ses cas d’échec.

Erreur qui tue : vendre une “autonomie” là où le CHU veut du support à la décision, avec une chaîne de validation claire.

Bloc 4 : sécurité, interopérabilité, intégration DSI

Une startup qui gagne du temps au CHU est une startup qui réduit l’effort de la DSI, pas l’inverse.

• Architecture : où tourne l’inférence (on-prem, hébergement, hybride), séparation environnements, chiffrement.
• Authentification : comment un pro de santé se connecte, et comment tu gères les droits. La doctrine numérique en santé met en avant des briques de confiance comme Pro Santé Connect.
• Interop : formats, API, compatibilité avec l’existant (DPI, PACS, RIS, etc.). Tu n’as pas besoin de tout promettre, mais tu dois être clair sur ce qui est possible.
• Logs et audit : journalisation, traçabilité des accès, alerting minimal.
• Plan de réversibilité : si on arrête, comment on récupère données, résultats, configurations.

Erreur qui tue : “On a une API, ça s’intègre.” Oui, mais dans un CHU, l’API est le début des problèmes, pas la fin.

Bloc 5 : dossier technique et qualité (niveau “pilotable”)

Sans tomber dans la paperasse infinie, tu dois prouver que tu sais documenter.

• Description produit : indications d’usage, limites, prérequis.
• Gestion des risques : liste des scénarios d’échec, mesures de mitigation, procédures de dégradation.
• Gestion des changements : si tu mets à jour le modèle pendant le pilote, comment tu le fais, comment tu le traces.
• Plan de support : qui répond, sous quels délais, pendant l’essai.
• Éléments DM si pertinent : ta position actuelle (DM ou pas), ce que tu vises, et ta trajectoire. Les ressources G_NIUS sont utiles pour cadrer par où commencer (marquage CE, SMQ).

Erreur qui tue : “On est trop early pour documenter.” Non. Si tu es trop early pour décrire risques et usage, tu es trop early pour un CHU.

Bloc 6 : modalités d’évaluation et “contrat psychologique” du POC IA santé

Un POC IA santé n’est pas un terrain gratuit. C’est un échange. Tu demandes du temps clinique, de la bande passante DSI, parfois de l’accès à des données sensibles. Tu dois poser un cadre.

• Périmètre : service, site, nombre de cas, durée.
• Ressources : qui fait quoi (CHU vs startup), heures estimées, points de validation.
• Critères stop/go : noir sur blanc. Si tu ne les proposes pas, le CHU te les imposera, ou ne fera rien.
• Mesure : comment tu collectes les métriques sans rajouter une charge de saisie absurde.
• Propriété des résultats : ce que tu peux réutiliser (apprentissage, amélioration), sous quelles conditions.

Erreur qui tue : “On fait un POC pour prouver.” Prouver quoi, à qui, avec quel critère, et quel coût ? Si tu ne sais pas répondre, tu es en mode vitrine.

Comment mener tes rendez-vous sur place (et ne pas passer pour un touriste)

À un événement comme HealthTech Connexion Day Lyon, tu vas parler à des profils très différents. Ton objectif est d’identifier vite le bon chemin décisionnel.

Ta trame en 90 secondes

• Cas d’usage : “On adresse X dans le service Y, à l’étape Z du parcours.”
• Décision clinique impactée : ce qui change concrètement.
• Preuve existante : une perf mesurée, même sur petit jeu, mais honnête.
• Prérequis : données nécessaires, intégration minimale, contraintes sécurité.
• Proposition de pilote : durée, volume, critères stop/go, effort estimé côté CHU.

Les questions à poser (celles qui te font passer au niveau “partenaire”)

• Qui est sponsor clinique et qui est sponsor “run” (DSI, qualité) ?
• Quel irritant prioritaire dans le service aujourd’hui (délai, surcharge, perte de chance, réadmissions, etc.) ?
• Quelle capacité réelle à conduire un pilote sur le trimestre (disponibilité, projets en cours, migrations) ?
• Quel cadre d’accès aux données est envisageable (sur site, environnement sécurisé, export limité) ?
• Quels critères cliniques sont “décisifs” pour eux, pas pour toi ?

Ce que tu dois obtenir pour que l’événement serve à quelque chose

Tu ne repars pas avec “on reste en contact”. Tu repars avec un paquet minimum. Sinon, tu as juste fait de la figuration.

• Un prochain rendez-vous daté (30 minutes, visio ou sur site) avec au moins un clinicien sponsor et un contact “numérique” (DSI ou équivalent).
• Un cadrage de pilote : service, périmètre, durée, volumétrie cible.
• Un cadre d’accès aux données acceptable : où, comment, avec quel hébergement, quelles contraintes DPO.
• Des critères cliniques et opérationnels écrits : critère principal, 2 ou 3 secondaires, et un stop/go.
• Une liste claire des parties prenantes à embarquer (qualité, biomédical, cybersécurité, achats, recherche si applicable).

Si tu obtiens ça, tu as une vraie trajectoire de collaboration CHU IA. Si tu n’obtiens rien de tout ça, ton “réseau” ne se transformera pas en projet.

Deux liens utiles côté Lyon IA si tu veux cadrer proprement (sans t’inventer une méthode)

• Cadrer un projet IA : la méthode en quatre étapes avant d’écrire du code
• Tracer les décisions prises avec l'aide d'une IA

Plan d’action J-15 pour arriver prêt au CHU HealthTech Connexion Day #5

• J-15 à J-10 : écrire ton cas d’usage sur 1 page (problème, population, critère principal, comparateur, périmètre pilote).
• J-10 à J-7 : faire ton schéma données (flux, accès, HDS si nécessaire, traçabilité) et le valider en interne.
• J-7 à J-5 : préparer tes réponses sécurité et intégration (auth, logs, réversibilité, contraintes CHU).
• J-5 à J-2 : préparer une proposition stop/go et un mini-calendrier pilote (avec charge estimée côté CHU).
• Jour J : viser 5 discussions profondes plutôt que 30 cartes de visite. Et demander un rendez-vous daté à chaque fois.

Tu veux faire simple ? Fais simple, mais fais carré. Au CHU, ce n’est pas ton modèle qui fait la différence. C’est ta capacité à rendre un pilote faisable, mesurable, sûr, et acceptable pour ceux qui soignent.