Santé, finance et secteur public : pourquoi toutes les données d’IA ne peuvent pas partager la même infrastructure

Par StratoSentry - 12 janvier 2026

Les modèles d’intelligence artificielle promettent des gains de productivité dans la santé, la finance et l’administration publique. Pourtant, les exigences de confidentialité, de conformité réglementaire et de résilience opérationnelle divergent fortement entre ces secteurs. Partager une infrastructure unique – que ce soit un cloud public, un datacenter interne ou une plateforme d’entraînement – expose chaque domaine à des risques juridiques, techniques et organisationnels incompatibles. Cet article décortique les spécificités de chaque filière, analyse les contraintes d’isolation, de souveraineté et de performance, puis propose des architectures hybrides capables de concilier IA et exigences sectorielles sans compromis inacceptables.

Introduction : une poussée de l’IA qui rencontre des frontières juridiques et techniques

En 2023, le marché mondial de l’intelligence artificielle a dépassé les 200 milliards d’euros, avec une adoption rapide dans la santé (diagnostic assisté, suivi de patients), la finance (détection de fraude, gestion de portefeuille) et le secteur public (analyse de données publiques, services aux usagers). Les organisations cherchent à mutualiser leurs plateformes d’entraînement afin de réduire les coûts d’infrastructure : un même cluster GPU, le même stockage objet ou la même solution de MLOps pourraient théoriquement servir plusieurs cas d’usage.

Or, chaque secteur opère sous des cadres réglementaires distincts (RGPD et HDS pour la santé, PCI‑DSS et GLBA aux États-Unis, NIS 2 pour les services publics) et possède des exigences de souveraineté des données, de disponibilité et de traçabilité qui ne sont pas compatibles entre elles. La tentation d’une « single‑tenant AI platform » se heurte rapidement à des contradictions : comment garantir la confidentialité d’un dossier médical tout en traitant simultanément des flux boursiers ultra‑sensibles ?

Ce constat conduit les DSI, RSSI et responsables IA à repenser l’architecture de leurs environnements d’apprentissage. Plutôt que de viser une uniformisation totale, il faut identifier quels actifs, quelles politiques et quels déploiements doivent rester isolés, puis concevoir des ponts sécurisés entre eux.

1. Panorama réglementaire : exigences différenciées selon les secteurs

Ces cadres imposent des contrôles différents :

• Chiffrement : la santé requiert un chiffrement de bout en bout avec gestion séparée des clés (exigence HDS). La finance impose souvent le FIPS 140‑2 pour les modules cryptographiques. Le secteur public peut être soumis à des exigences de chiffrement homologué par l’État (ANSSI).
• Traçabilité : la finance doit produire des journaux d’accès conformes à PCI‑DSS, alors que la santé se concentre sur le registre des traitements (RGPD Art. 30). Le secteur public doit garantir la conservation des logs pendant 10 ans pour les services critiques (NIS 2).
• Résilience : les systèmes de santé ne tolèrent pas plus de 5 minutes d’indisponibilité en cas d’urgence, alors que le secteur financier vise < 1 minute de latence pour les transactions à haute fréquence. Le public impose des plans de continuité (PCP) spécifiques aux services de l’État.

Ces exigences incompatibles rendent impossible la mutualisation totale d’une infrastructure sans mécanismes d’isolation robustes.

2. Risques techniques d’un partage unique : quand l’interopérabilité devient vulnérabilité

• Fuite transversale de données (cross‑tenant leakage)
• Dans un environnement multi‑tenant, une mauvaise configuration des contrôles d’accès peut permettre à un modèle entraîné sur des dossiers patients d’être exposé aux équipes finance via le même stockage objet. La moindre faille du IAM (Identity and Access Management) devient alors un vecteur de violation du RGPD Art. 9.

• Contamination des modèles
• Les biais présents dans les jeux de données santé peuvent se propager à des modèles financiers si les pipelines d’entraînement partagent le même registre de métadonnées. Cette « model poisoning » compromet la fiabilité des algorithmes de détection de fraude, avec des conséquences réglementaires (PCI‑DSS 12.2).

• Contraintes de conformité conflictuelles
• La mise en œuvre d’un chiffrement homomorphe compatible avec les exigences HDS peut être incompatible avec les performances requises pour le calcul haute fréquence du secteur financier, créant un dilemme entre sécurité et latence.

• Défaillance de la souveraineté des données
• Un fournisseur de cloud public basé hors UE pourrait héberger des données santé (soumis au RGPD) tout en stockant simultanément des flux financiers soumis à la loi américaine Gramm‑Leach‑Bliley. Le transfert transfrontalier non autorisé expose l’organisation à des sanctions pouvant atteindre 4 % du chiffre d’affaires annuel mondial.

Ces risques montrent que le principe de moindre privilège et l’isolation physique ou logique sont indispensables pour chaque domaine d’activité.

3. Architectures d’isolation : options techniques éprouvées

3.1 Isolation physique (bare‑metal, zones dédiées)

• Datacenters souverains : serveurs dédiés à la santé hébergés dans un cloud souverain certifié HDS, avec des réseaux séparés (VLAN/VRF) pour la finance et le public.
• Avantages : garantie de séparation totale des flux, conformité aux exigences de résidence des données.
• Inconvénients : coûts d’infrastructure élevés, sous‑utilisation potentielle des ressources GPU.

3.2 Isolation logique (virtualisation, conteneurs, réseaux définis par logiciel)

3.3 Approches hybrides

• Data Mesh souverain : chaque domaine possède son domain data product avec gouvernance locale, mais les modèles d’IA peuvent être entraînés via du federated learning où les paramètres sont agrégés sans échange de données brutes.
• Edge‑AI pour la santé : traitement des images médicales directement sur le dispositif (ex. scanner IRM) afin que les données ne quittent jamais le périmètre hospitalier, tandis que les modèles d’inférence financière restent dans le cloud public.

Ces architectures permettent de concilier efficacité économique (réutilisation de GPU partagés) et conformité sectorielle grâce à des frontières clairement définies.

4. Gestion du cycle de vie des données IA : gouvernance adaptée aux secteurs

• Ingestion
• Santé : utilisation de FHIR (Fast Healthcare Interoperability Resources) avec chiffrement TLS‑1.3 et authentification forte via OAuth2 + OpenID Connect.
• Finance : flux FIX ou SWIFT sécurisés, validation des signatures numériques.
• Public : APIs ouvertes conformes au standard OpenAPI mais protégées par des jetons d’accès à durée limitée.

• Stockage
• Santé : stockage objet certifié HDS avec immutability (WORM) et versionning obligatoire.
• Finance : bases de données chiffrées au repos, logs d’audit séparés selon PCI‑DSS 10.5.1.
• Public : data lake souverain conforme à la directive NIS 2, avec zone de données sensibles distincte.

• Entraînement
• Utilisation de clusters GPU dédiés par domaine ou d’instances spot réservées pour les workloads non critiques (exemple : recherche académique dans le secteur public).
• Application du principe data minimization : ne charger que les colonnes nécessaires à l’entraînement, afin de réduire la surface d’exposition.

• Déploiement
• Santé : modèles empaquetés en conteneurs signés (Docker Content Trust) et déployés dans des environnements certifiés HDS.
• Finance : utilisation de model serving avec chiffrement des poids (ex. Homomorphic Encryption for Model Inference) pour les services à haute valeur ajoutée.

• Archivage & retrait
• Conformité aux exigences de conservation : 10 ans pour les logs financiers, 15 ans pour les dossiers patients en France. Utilisation de cold storage (Glacier, Azure Archive) avec purge automatisée après expiration des obligations légales.

5. Cas d’usage illustratif : plateforme IA hybride au service d’un hôpital public et d’une banque régionale

Contexte

Un groupe hospitalier français souhaite déployer un modèle de diagnostic assisté par IA (détection précoce du cancer du poumon à partir de scanners CT). Simultanément, la même collectivité territoriale possède une filiale bancaire qui veut mettre en place un système de détection de fraude en temps réel. Les deux entités partagent le même fournisseur de cloud souverain (ex. Orange Cloud for Business), mais leurs exigences diffèrent radicalement.

Architecture proposée

Points forts

• Isolation physique du stockage (HDS vs chiffrement PCI).
• Namespaces Kubernetes distincts, avec NetworkPolicies empêchant tout trafic inter‑zone.
• Federated Learning permet de partager des connaissances (ex. détection d’anomalies) sans échanger les données brutes, respectant ainsi le principe de minimisation.

Résultats attendus (hypothétiques, basés sur études de cas publiées)

Ce scénario montre que l’isolation ciblée permet de réaliser des économies d’échelle tout en respectant les exigences règlementaires propres à chaque secteur.

6. Points de vigilance : pièges fréquents et mesures d’atténuation

Sécurité & conformité

Gouvernance

• Mettre en place un Comité d’Architecture IA transversal incluant DSI, RSSI, DPO et représentants métiers des trois secteurs.
• Formaliser les politiques de rétention et les processus de purge dans le catalogue de services cloud.
• Instaurer des indicateurs de suivi (KPI) : % de workloads isolés, nombre d’incidents de fuite, temps moyen de mise en conformité après changement réglementaire.

7. Décision stratégique : comment choisir l’architecture la plus adaptée

| Complexité réglementaire | Comb

Retour au blog