IA médicale : pourquoi l'Europe doit opérer ses propres modèles plutôt que consommer des APIs américaines

# IA médicale : pourquoi l'Europe doit opérer ses propres modèles plutôt que consommer des APIs américaines

En 2026, le secteur de la santé européen est à la croisée des chemins. L'IA s'est imposée dans les workflows cliniques — aide au diagnostic, synthèse de dossiers patients, triage, pharmacovigilance. Mais la majorité des déploiements reposent aujourd'hui sur des appels à des APIs fermées opérées par des acteurs américains, dont les infrastructures, les modèles et les conditions contractuelles échappent au droit européen. Ce n'est pas une question de performance technique. C'est une question d'architecture de souveraineté.

Cet article compare trois approches de déploiement de l'IA en milieu de santé selon quatre critères : architecture de traitement des données, exposition juridique extraterritoriale, capacité d'audit et de gouvernance du modèle, et intégration avec les référentiels de conformité européens.

Les trois approches en présence

Approche A — API fermée d'un opérateur américain dominant

Le modèle est hébergé et opéré hors UE, ou dans des datacenters UE mais sous juridiction US. L'accès se fait via des appels REST. Le modèle n'est pas auditable, les poids ne sont pas accessibles, les conditions de traitement des données sont régies par des contrats de droit américain.

Approche B — Modèle open-weight déployé sur infrastructure européenne souveraine

Un modèle à poids ouverts — par exemple Meditron, développé à l'EPFL, ou BioMedLM, issu de la recherche européenne — est déployé sur une infrastructure certifiée HDS (Hébergeur de Données de Santé) opérée en Europe. L'opération est assurée par l'établissement de santé ou un prestataire européen qualifié.

Approche C — Consortium d'opérateurs européens mutualisés

Plusieurs établissements de santé ou groupements hospitaliers mutualisent l'infrastructure et la gouvernance d'un modèle spécialisé, via une structure de droit européen (GIE, GCSMS ou équivalent). Le modèle est fine-tuné sur des données pseudonymisées sous contrôle collectif.

Critère 1 — Architecture de traitement des données

Approche A

Les données patients transmises à une API fermée américaine — même anonymisées ou pseudonymisées — transitent par des systèmes dont l'opérateur maîtrise l'intégralité du pipeline de traitement. La pseudonymisation ne constitue pas une garantie absolue dès lors que le fournisseur dispose de capacités de réidentification potentielle via d'autres signaux contextuels. Par construction, l'architecture est centralisée côté fournisseur : aucune donnée de requête ne reste sous contrôle local.

Approche B

Le traitement est intégralement local (on-premise ou cloud souverain HDS). Les données ne quittent pas le périmètre de l'infrastructure contrôlée. L'inférence se fait sur des GPU loués ou possédés par l'établissement. La latence est maîtrisée, et l'ensemble du flux est journalisé sous la responsabilité du responsable de traitement européen.

Approche C

Architecture fédérée ou mutualisée : les données ne sont jamais centralisées au niveau du consortium. Seuls les paramètres de fine-tuning ou les gradients circulent entre nœuds, selon les implémentations. Le modèle partagé est hébergé sur une infrastructure dont la gouvernance est contractuellement européenne. C'est l'approche la plus complexe à opérer, mais celle qui offre le meilleur rapport entre mutualisation des coûts et étanchéité des données.

Critère 2 — Exposition juridique extraterritoriale

C'est ici que le différentiel entre les approches est le plus structurant pour un DSI ou un RSSI européen.

Approche A

L'exposition au Cloud Act américain est directe et non contournable. Quel que soit le datacenter physique utilisé, un opérateur américain est légalement contraint de transmettre des données à des autorités américaines sur injonction judiciaire, y compris sans notification préalable au client. Pour des données de santé — considérées comme données sensibles au sens de l'article 9 du RGPD — cette exposition constitue un risque juridique de premier ordre. Aucune clause contractuelle ne peut y déroger : le droit américain prime sur le contrat commercial.

Par ailleurs, les Executive Orders américains successifs en matière de contrôle des technologies d'IA étendent le périmètre d'intervention potentielle des autorités américaines sur les modèles exportés ou opérés depuis les États-Unis.

Approche B

L'exposition extraterritoriale est nulle si le prestataire d'infrastructure est de droit européen et ne dispose pas de structure juridique aux États-Unis. La qualification HDS impose un audit de la chaîne d'hébergement. Le responsable de traitement reste l'établissement de santé, ce qui est conforme au principe d'accountability du RGPD.

Approche C

Même logique que l'approche B, renforcée par la structure juridique collective. La multiplicité des parties prenantes européennes rend toute injonction extraterritoriale politiquement et juridiquement plus complexe à exécuter. C'est un effet de masse souveraine.

Critère 3 — Auditabilité et gouvernance du modèle

Approche A

Le modèle est une boîte noire. L'établissement de santé ne peut pas auditer les paramètres du modèle, sa chaîne d'entraînement, les biais potentiels introduits par les données d'apprentissage, ni les mises à jour silencieuses de comportement. Dans un contexte médical, cela pose un problème direct de conformité avec l'AI Act européen (entré en application progressive depuis 2025), qui classifie les systèmes d'IA à usage médical dans les catégories à haut risque — avec des exigences explicites de transparence, de traçabilité et de supervision humaine.

Approche B

Les poids du modèle sont accessibles et auditables. Un établissement peut missionner un tiers de confiance pour auditer la chaîne d'entraînement, documenter les biais, et produire la documentation technique exigée par l'AI Act. Le modèle peut être figé sur une version validée, ce qui est impossible avec une API dont le fournisseur met à jour unilatéralement le backend.

Approche C

La gouvernance est formalisée au niveau du consortium. Les décisions de mise à jour, de fine-tuning ou de retrait du modèle sont collectives et traçables. C'est la seule approche qui permet une gouvernance distribuée de l'IA médicale à l'échelle d'un territoire ou d'une spécialité. Elle est cependant exigeante en termes de coordination et de maturité organisationnelle des parties.

Critère 4 — Conformité RGPD, NIS2 et référentiels sectoriels

| Critère | API fermée US | Modèle open-weight souverain | Consortium européen mutualisé |

|---|---|---|---|

| Base légale transfert hors UE | Fragile (clauses contractuelles types insuffisantes post-Schrems) | Non applicable | Non applicable |

| Qualification HDS possible | Non (hors contrôle) | Oui | Oui |

| Conformité AI Act (haut risque) | Difficile à documenter | Auditable et documentable | Auditable, gouvernance traçable |

| Conformité NIS2 (résilience) | Dépendance à un tiers hors UE | Maîtrise locale | Redondance collective |

| Portabilité et réversibilité | Verrouillage fort (vendor lock-in) | Totale | Totale |

| Traçabilité des décisions IA | Opaque | Assurée | Assurée et collective |

La conformité NIS2, applicable aux opérateurs de services essentiels dont font partie les établissements de santé de taille critique, exige désormais une cartographie et une maîtrise des dépendances tierces. Une dépendance à une API unique opérée hors UE constitue un point de défaillance unique (SPOF) sur un service critique — ce qui est explicitement adressé par les obligations de gestion du risque fournisseur sous NIS2.

Ce que cela implique concrètement pour un DSI de santé

La question n'est pas de savoir si les modèles américains sont techniquement performants. Elle est de savoir si un établissement de santé européen peut légalement, éthiquement et stratégiquement déléguer l'opération de son IA médicale à une infrastructure qu'il ne contrôle pas, régie par un droit étranger, et dont il ne peut pas auditer le comportement.

En 2026, la réponse réglementaire européenne est de plus en plus claire : non. L'AI Act, le RGPD, NIS2 et les référentiels HDS convergent vers une exigence de souveraineté opérationnelle sur les systèmes d'IA à haut risque en milieu médical.

Les approches B et C ne sont pas des compromis techniques dégradés. Elles sont des architectures de conformité. Le déploiement d'un modèle open-weight sur infrastructure HDS est aujourd'hui techniquement mature — plusieurs CHU français et des groupements hospitaliers allemands ont initié cette transition. La logique de consortium, plus complexe à monter, est en revanche la seule qui permette de mutualiser les coûts d'opération GPU et de gouvernance à l'échelle nécessaire pour les établissements de taille intermédiaire.

La vraie question pour un DSI n'est donc plus technique. Elle est organisationnelle et politique : l'établissement est-il prêt à investir dans la gouvernance de son IA, ou préfère-t-il déléguer cette responsabilité à un opérateur américain dont les intérêts et les obligations légales ne coïncident pas avec les siens ?