Twinsight (Grenoble) lève 1,6 M€ : jumeau numérique santé, opportunités et pièges en AURA

Une levée à Grenoble qui dit plus que “1,6 M€” Twinsight, basée à La Tronche près de Grenoble, a finalisé une levée de fonds de 1,6 M€ durant l’été 2026, dans une opération mixte (equity + non dilutif...

Jimmy Manin Publié le 17 octobre 2026 11 min de lecture

Twinsight (Grenoble) lève 1,6 M€ : jumeau numérique santé, opportunités et pièges en AURA

Une levée à Grenoble qui dit plus que “1,6 M€”

Twinsight, basée à La Tronche près de Grenoble, a finalisé une levée de fonds de 1,6 M€ durant l’été 2026, dans une opération mixte (equity + non dilutif) avec mention de soutiens Bpifrance et de banques régionales dans la presse économique. Source : Le Dauphiné.

Le produit mis en avant : un logiciel de simulation biomécanique et de jumeau numérique orthopédique pour préparer des interventions, avec l’exemple récurrent de la prothèse de genou (planification, choix et positionnement). Même source.

Ce signal est régional. Grenoble coche les cases : recherche (TIMC-IMAG), CHU, imagerie, startups deeptech. Le TIMC-IMAG cite TwInsight/Twinsight parmi les sociétés issues ou appuyées, avec une mission explicite autour du jumeau numérique orthopédique et des briques logicielles (segmentation, landmarking, cinématique). Source : TIMC-IMAG.

Mais surtout, cette levée rappelle une réalité : le jumeau numérique santé n’est plus juste un concept. En Auvergne-Rhône-Alpes, il est en train de se brancher sur une base critique : les entrepôts de données de santé (EDS) des CHU, et leur mise en réseau.

Pourquoi AURA est un terrain logique pour les jumeaux numériques en santé

Deux briques structurent le passage à l’échelle.

Les données : le GCS HOURAA réunit les 4 CHU de la région (Clermont-Ferrand, Grenoble Alpes, Lyon, Saint-Étienne) et porte la mise en réseau des EDS via DataHubHOURAA (D2H). Source : HCL - feuille de route HOURAA.
L’interopérabilité cible : D2H est présenté comme lauréat (France 2030, vague 2) avec l’objectif d’EDS “partagés, convergents, interopérables”. Source : HCL - DataHubHOURAA.

Grenoble illustre déjà la trajectoire “EDS + imagerie + jumeaux numériques personnalisés”. Le CHU Grenoble Alpes décrit un projet visant à créer des jumeaux numériques personnalisés à partir d’images CT scan issues de l’entrepôt, en s’appuyant sur des technos du TIMC et de TwInsight. Source : CHU Grenoble Alpes - EDS.

À Lyon, les HCL mettent en avant la structuration IA et données et la concrétisation de D2H, avec une mise en production d’EDS “jumeaux” (Lyon et Grenoble cités). Source : HCL - IA et données.

Traduction simple : l’écosystème IA santé Auvergne-Rhône-Alpes a les tuyaux. Maintenant, il faut faire des cas utiles, validés, sécurisés. Et éviter les pilotes gadgets.

1) Cas d’usage réalistes en AURA : où ça crée de la valeur (et où ça déraille)

Cas n°1 : parcours patient en orthopédie, du préop au suivi

Le cas Twinsight est typique : on part d’imagerie (scanner), on reconstruit un modèle patient-spécifique, on simule, puis on aide à décider. L’objectif opérationnel est clair : mieux planifier (tailles d’implants, positionnement), réduire l’incertitude et, potentiellement, diminuer variabilité et reprises. Source produit et focus genou : Le Dauphiné.

Pour un hôpital AURA, la valeur se joue sur des indicateurs “terre à terre” :

temps de préparation préopératoire par cas (chir, radio, ingénierie clinique),
qualité peropératoire (alignement cible, gestes additionnels évités),
durée bloc, variabilité, consommation de plateaux,
récupération fonctionnelle et complications (à mesurer avec méthode, pas au doigt mouillé).

Le point dur n’est pas la 3D. C’est l’intégration au flux réel : PACS, RIS, DPI, comptes rendus, et la capacité à “boucler” avec les résultats post-op pour apprendre.

Cas n°2 : cardiologie, promesse forte, routine pas encore là

Les HCL évoquent des travaux de jumeaux numériques en cardiologie et insistent sur un point que beaucoup oublient : c’est prometteur, mais pas encore en routine. Source : Fondation HCL.

Ça doit guider les attentes. Pour un jumeau numérique santé, “ça marche en recherche” ne suffit pas. En routine, il faut :

un délai compatible avec la décision médicale,
des entrées standardisées (imagerie, mesures, contexte clinique),
une robustesse aux cas atypiques,
et une validation clinique béton.

Cas n°3 : simulation “in silico” pour industriels medtech et dispositifs

Côté industriels AURA (conception et fabrication de dispositifs, orthopédie, instrumentation), le jumeau numérique ouvre des usages moins visibles mais très rentables :

cohortes virtuelles pour tester un dispositif sur des morphologies variées,
réduction de cycles de prototypes et d’essais physiques,
analyse de sensibilité (qu’est-ce qui fait varier le résultat ?),
préparation réglementaire avec un dossier de justification plus structuré.

Attention : la simulation ne remplace pas magiquement l’essai. Elle peut réduire, cibler, documenter. À condition de définir un périmètre de validité (population, indications, imagerie requise, hypothèses biomécaniques).

Cas n°4 : approche modulaire, briques plutôt que “plateforme totale”

Un point concret issu de Grenoble : TIMC-IMAG indique que TwInsight commercialise aussi des composants pour automatiser des étapes comme segmentation, landmarking, etc. Source : TIMC-IMAG.

Pour un hôpital ou un industriel, c’est une option stratégique : acheter une brique intégrable (exemple segmentation validée) plutôt qu’une plateforme monolithique qui vous enferme. Moins sexy. Souvent plus déployable.

2) Prérequis de déploiement : données, interop, validation, cyber, MLOps

Un jumeau numérique personnalisé, c’est un pipeline. Si une étape est fragile, tout le reste s’écroule. Voilà les prérequis qui reviennent systématiquement sur le terrain en IA santé Auvergne-Rhône-Alpes.

Interopérabilité : sinon tu fais un pilote “hors-sol”

Le risque numéro un : une démo qui marche sur un export manuel. Et qui meurt dès que tu veux industrialiser.

Point de repère : l’ANS pousse FHIR comme standard socle sur plusieurs catégories de données (résumé patient, prescriptions, imagerie et comptes rendus, biologie, sorties). Source : ANS - eSanté.gouv.fr.

Ce que tu veux dès le départ :

connecteurs PACS et imagerie cadrés (formats, métadonnées, traçabilité),
identité patient propre (INS), gestion des professionnels (RPPS) quand pertinent,
un plan clair de “ce qui part dans le jumeau” et “ce qui reste dans le SIH”.

Qualité des données : le jumeau numérique ne pardonne pas

En orthopédie et en imagerie, la qualité est tout : artefacts, protocoles hétérogènes, annotations manquantes, variabilité inter-sites. Tu peux avoir un EDS énorme, et un dataset inutilisable pour ton usage précis.

Le CHU Grenoble Alpes mentionne un ordre de grandeur de son EDS (1,1 million de patients sur 10 ans). Source : CHU Grenoble Alpes - EDS.

Volume ne veut pas dire “prêt”. Pour un pilote, tu veux une check-list :

définition stricte de la population (critères d’inclusion et d’exclusion),
standardisation des acquisitions (ou au moins cartographie des variations),
traçabilité des labels et des corrections manuelles,
gestion des données manquantes et des cas limites.

Validation IA médicale : le sujet qui décide si ça sort du labo

Le mot-clé à retenir : validation IA médicale. Pas au sens “on a comparé sur 20 cas”. Au sens preuve, reproductibilité, limites connues, surveillance.

Pour un jumeau numérique santé, la validation se joue sur trois niveaux :

validation technique : reconstruction, segmentation, stabilité numérique, sensibilité aux entrées, robustesse,
validation clinique : impact sur la décision, concordance avec des mesures de référence, outcomes (quand possible),
validation opérationnelle : délai, charge de travail, adoption par les équipes, fréquence des échecs et procédure de repli.

Le piège classique : faire une validation “data science” et oublier le contexte clinique. Un jumeau peut être très précis sur une métrique, et inutile au bloc parce que trop lent, trop complexe, ou non interprétable.

Cybersécurité : imagerie + modèles + réseau, combo à haut risque

Un jumeau numérique, c’est souvent un flux d’imagerie, des calculs lourds, parfois du cloud, et des accès à des systèmes critiques. Donc surface d’attaque plus large.

Avant même de parler “IA”, il faut exiger :

chiffrement en transit et au repos, gestion des clés,
journalisation exploitable (qui a accédé à quoi, quand, pourquoi),
droits au moindre privilège, séparation des environnements,
plan de réponse à incident (et pas un PDF oublié).

Si tu veux un rappel sec des questions à poser côté sécurité IA, tu peux t’appuyer sur cette grille publiée sur Lyon IA : https://lyon-ia.com/blog/ats26-lyon-0311-security-ai-10-questions-pour-securiser-genai-et-agents-ia.

MLOps et run : sinon ça devient un “prototype éternel”

Le jumeau numérique n’échappe pas à la règle : si tu ne sais pas l’opérer, tu ne le déploies pas. Points minimum :

versioning des modèles et des données,
monitoring (dérive, taux d’échec, latence, qualité),
procédure de rollback,
gouvernance de changement (qui valide une nouvelle version ?).

Pour cadrer le passage POC vers production, la checklist “POC vers run” côté DSI est utile, même si elle n’est pas spécifique santé : https://lyon-ia.com/blog/industrialiser-lia-en-dsi-a-lyon-1310-la-checklist-poc-vers-run-mlops-couts-risques.

3) Évaluer un pilote sans s’enfermer : méthode pour hôpital ou industriel en AURA

Le bon pilote n’est pas “on teste et on voit”. C’est un test qui te laisse libre : libre de continuer, d’arrêter, ou de changer de fournisseur sans tout jeter.

Étape 1 : cadrer le pilote comme un produit, pas comme une démo

Tu veux un document d’une page qui répond à :

Décision à améliorer (quoi, quand, qui décide),
Population (combien de cas, quel profil patient),
Entrées (imagerie, mesures, comptes rendus),
Sorties attendues (indicateurs, rapport, visualisation),
Mode dégradé (que fait-on si le jumeau échoue ?).

Si tu veux une structure de cadrage réutilisable, tu peux partir de la méthode Lyon IA “4 étapes avant d’écrire du code” : https://lyon-ia.com/blog/cadrer-un-projet-ia-methode.

Étape 2 : définir des critères de succès mesurables (et un stop clair)

Un pilote de jumeau numérique santé doit avoir des seuils, sinon tout le monde se raconte une histoire.

Exemples de critères utiles :

Performance : précision sur métriques pertinentes (ex : erreur de mesure, concordance), mais aussi taux de cas “inexploitables”.
Temps : temps total de production du jumeau (de l’imagerie à la recommandation).
Charge : minutes humaines par cas (radiologue, manipulateur, ingénieur, chirurgien).
Adoption : proportion de décisions réellement éclairées par l’outil, pas juste “on l’a regardé”.
Sécurité : exigences de logs, contrôle d’accès, tests de base (et conformité interne).

Et tu fixes un stop : si le taux d’échec dépasse X %, si le délai dépasse Y, si l’intégration SIH reste manuelle après Z semaines. Sinon tu te fais aspirer.

Étape 3 : achats et contrats, le point qui enferme le plus vite

Pour ne pas te verrouiller :

exige la portabilité des résultats et des données dérivées (formats exportables),
clarifie la propriété des annotations, modèles personnalisés, règles et paramétrages,
pose une clause sur l’accès aux métriques de performance et aux logs nécessaires à l’audit,
encadre l’hébergement et les sous-traitants (données de santé, responsabilités).

Sur la méthode d’achat IA et les points de vigilance, ce guide Lyon IA est une base solide : https://lyon-ia.com/blog/contrat-fournisseur-ia-clauses.

Étape 4 : gérer les risques sans tuer le projet

Un pilote réussi, c’est un pilote qui a prévu ses risques dès le début :

Risque clinique : mauvaise recommandation, mauvaise interprétation, surconfiance. Réponse : protocole d’usage, traçabilité, formation.
Risque données : biais de population, qualité variable, dérive. Réponse : monitoring, audits réguliers, jeux de tests.
Risque cyber : accès, exfiltration, indisponibilité. Réponse : exigences SSI, tests, plan de continuité.
Risque opérationnel : surcharge équipes. Réponse : design du flux, automatisation des étapes répétitives, support.

Pour structurer la traçabilité (qui a décidé quoi avec l’aide du système), cette ressource est directement actionnable : https://lyon-ia.com/blog/tracabilite-decisions-ia.

Ce que la région peut faire dès maintenant (hôpitaux, industriels, startups)

La levée de Twinsight n’est pas “juste” une actu startup. Elle illustre un mouvement : les jumeaux numériques personnalisés deviennent testables à l’échelle, parce que les EDS et la mise en réseau avancent en AURA (HOURAA, D2H) et parce que Grenoble a une chaîne recherche vers produit.

Trois actions simples, faisables, sans bullshit :

Hôpitaux : choisir un cas d’usage unique (orthopédie, cardio, autre), et monter un pilote branché sur le SI, pas sur des exports. S’appuyer sur des cadres d’expérimentation en conditions réelles quand c’est possible, par exemple la plateforme PLATINES (Lyon Sud) labellisée tiers-lieu d’expérimentation. Source : HCL Recherche.
Industriels medtech : prioriser un usage “in silico” où la simulation réduit vraiment le coût ou le délai, et documenter le périmètre de validité dès le départ. Pas après.
Écosystème AURA : pousser des approches modulaires (briques validées) plutôt que des plateformes fermées. C’est souvent comme ça que tu passes du pilote à la chaîne.

Si tu veux te faire une culture rapide côté jumeaux numériques (hors santé, mais utile pour la méthode et le cadrage), ce guide publié sur Lyon IA peut servir de point de départ : https://lyon-ia.com/blog/hackathon-ia-a-lyon-1510-creer-un-jumeau-numerique-en-une-matinee-mode-demploi.