Architecture technique d'une application e-santé : de l'infra au déploiement (2026)
10/05/2026
Quand on démarre une application e-santé en France, la question de l'architecture technique vient très vite. Hébergement HDS, chiffrement bout-en-bout, intégrations DMP/PSC, contraintes Ségur, traçabilité RGPD : la stack n'est pas la même que pour une app SaaS B2B classique, et chaque choix structurant a des implications réglementaires. Pourtant, la documentation côté éditeurs reste fragmentaire, et chaque équipe finit par réinventer son socle.
Chez Bob le développeur, on conçoit des architectures e-santé depuis 2017 sur des projets allant de la startup MVP au programme hospitalier (CareSentinel pour l'AP-HP). Cet article décrit l'architecture qu'on déploie aujourd'hui par défaut sur un projet e-santé sérieux : ses composants, ses choix d'isolation, son CI/CD compatible HDS et les pièges qu'on a appris à éviter.
L'essentiel en 30 secondes :
- L'architecture e-santé suit une stack standard (frontend → API → base chiffrée → stockage objet) avec des contraintes spécifiques HDS, RGPD et Ségur.
- Le chiffrement au repos (TDE, pgcrypto) est minimal ; le chiffrement applicatif des champs sensibles est le vrai sujet.
- Le CI/CD doit être pensé en contexte HDS : runners isolés, secrets gérés en KMS, audit complet des déploiements.
- L'observabilité doit scrubber les PHI par défaut : pas de NIR ni de nom dans les logs Sentry/Datadog.
- La résilience compte : RPO/RTO documentés, sauvegardes immuables, plan de continuité testé annuellement.
Vue d'ensemble : les sept couches d'une architecture e-santé
Une application e-santé moderne se découpe en sept couches qui ont chacune leurs propres exigences techniques et réglementaires.
┌────────────────────────────────────────────────────────┐
│ 1. Clients (Web, mobile RN, intégrations tierces) │
└────────────────────────────────────────────────────────┘
│ HTTPS + auth
┌────────────────────────────────────────────────────────┐
│ 2. Edge (CDN, WAF, rate limiting, mTLS) │
└────────────────────────────────────────────────────────┘
│
┌────────────────────────────────────────────────────────┐
│ 3. API (NestJS / FastAPI, OIDC, RBAC, audit) │
└────────────────────────────────────────────────────────┘
│
┌────────────────────────────────────────────────────────┐
│ 4. Domaine (services métier, règles cliniques) │
└────────────────────────────────────────────────────────┘
│
┌─────────────────────────┴──────────────────────────────┐
│ 5. Persistance │
│ PostgreSQL chiffré │ S3 HDS │ Redis │ Search index │
└────────────────────────────────────────────────────────┘
│
┌────────────────────────────────────────────────────────┐
│ 6. Intégrations (DMP, MSSanté, PSC, INSi, FHIR) │
└────────────────────────────────────────────────────────┘
│
┌────────────────────────────────────────────────────────┐
│ 7. Plateforme (HDS, IaC, CI/CD, observabilité) │
└────────────────────────────────────────────────────────┘
On va dérouler ces couches en partant du bas (plateforme) qui conditionne tout le reste, puis remonter.
Couche plateforme : choisir son hébergeur HDS
Tout part de l'hébergeur. La certification HDS impose des exigences précises sur la sécurité physique, organisationnelle, la sauvegarde et la gestion des incidents. Quatre hébergeurs dominent le marché français : OVHcloud, Scaleway, AWS (région Paris) et Microsoft Azure (région France Central). Le détail de leurs offres respectives est dans notre comparatif des hébergeurs HDS.
Le choix dépend de trois critères principaux :
- Souveraineté : OVHcloud et Scaleway sont 100 % français. AWS et Azure sont des hyperscalers américains avec des engagements de localisation européenne.
- Catalogue managé : AWS et Azure proposent un catalogue de services managés très large (RDS, Lambda, S3, Cognito). OVHcloud et Scaleway sont plus limités, ce qui pousse à plus d'auto-hébergement.
- Maturité Kubernetes : tous proposent du Kubernetes managé, avec des niveaux de maturité différents. Si vous partez sur K8s, vérifiez la compatibilité HDS de l'offre managée précisément (le contrôle plane peut être en dehors).
En pratique, on déploie souvent sur AWS Paris ou OVHcloud selon la sensibilité du client à la souveraineté, et on garde la portabilité via Terraform et Kubernetes.
Infrastructure as Code et reproductibilité
Pour passer un audit HDS sereinement, la reproductibilité de l'infrastructure est non négociable. L'IaC en pratique :
- Terraform pour le provisioning cloud (VPC, subnets, IAM, RDS, S3).
- Helm + Kustomize pour le déploiement applicatif sur Kubernetes.
- GitOps (ArgoCD ou Flux) pour la synchronisation déclarative entre repo et cluster.
- Secrets en KMS (AWS KMS, OVH KMS, ou external-secrets-operator avec Vault).
- Audit log complet sur les changements infra, conservé 12 mois minimum.
Cette discipline IaC paie au moment des audits HDS : vous démontrez la traçabilité, la reproductibilité et la séparation des environnements en quelques minutes au lieu de plusieurs jours de fouille.
CI/CD compatible HDS
Le CI/CD est souvent négligé dans les architectures e-santé alors qu'il manipule à la fois du code, des secrets et parfois de la donnée de test. Les exigences HDS appliquées au CI/CD :
- Runners hébergés HDS : si votre pipeline tourne sur GitHub Actions cloud ou GitLab.com, vos runners ne sont pas HDS. Pour les jobs qui touchent aux environnements de prod ou pré-prod avec données réelles, utilisez des runners self-hosted dans votre infra HDS.
- Secrets en KMS : pas de credentials en clair dans les variables d'environnement. Utilisez des solutions type OIDC GitHub Actions → AWS IAM avec rôles temporaires.
- Tests d'intégration sur données synthétiques : jamais de prod copiée vers les environnements de dev/CI. Générer des fixtures réalistes avec Faker + règles métier.
- Build reproductibles : lockfiles versionnés, base images figées sur sha256, SBOM généré à chaque build.
- Signature d'images : Cosign ou Sigstore pour signer les images container, vérifiées au déploiement.
- Audit complet : qui a déclenché quel déploiement, vers quel environnement, avec quel SHA. Conservé 12 mois.
Cette structure rend le CI/CD un peu plus lourd à mettre en place mais protège massivement en cas d'incident ou d'audit.
Couche persistance : PostgreSQL et chiffrement
Pour 95 % des applications e-santé, PostgreSQL est le bon choix. Mature, supporté par tous les hébergeurs HDS, riche en extensions (pgcrypto, pgvector, postgis), et avec un écosystème ORM solide (Prisma, TypeORM, SQLAlchemy).
Quatre niveaux de chiffrement à connaître :
1. Chiffrement au repos (TDE). Activé par défaut sur AWS RDS, Azure Database, OVH Managed Postgres. C'est le minimum syndical : si quelqu'un vole le disque physique, il ne peut pas lire les données. Insuffisant face à un attaquant qui obtient un accès logique à la base.
2. Chiffrement en transit (TLS). Connexions clients → base et réplications inter-nœuds en TLS 1.2+ avec validation de certificat. Aucun client en clair.
3. Chiffrement applicatif des champs sensibles. Chiffrer dans l'application certains champs (NIR, INS, identifiants secondaires, contenu médical libre) avant insertion. Clés gérées en KMS, rotation possible. C'est ce qui protège vraiment contre une exfiltration logique.
4. Tokenisation et pseudonymisation. Pour les usages analytics, remplacer les identifiants directs par des tokens dans une base distincte. Permet de croiser des données sans réidentification possible côté analystes.
L'erreur classique : se contenter du TDE et considérer que la base est protégée. Un dump SQL légitime exfiltré reste lisible. Le chiffrement applicatif sur les champs sensibles est le vrai sujet.
Stockage objet : S3 et fichiers médicaux
Les fichiers médicaux (PDF, DICOM, photos) vont dans un stockage objet HDS. Trois règles :
- Bucket privé exclusif : pas d'accès public, jamais. Accès via URL signées avec expiration courte.
- Chiffrement côté serveur (SSE-KMS) avec clé client si possible.
- Versioning + Object Lock sur les buckets critiques (sauvegardes, archives) pour résister aux ransomwares.
Pour les volumes importants (imagerie médicale), prévoyez un tiering : chaud → tiède → froid avec règles de cycle de vie.
Couche API : NestJS, RBAC et auditabilité
Sur le backend, NestJS est notre choix par défaut depuis plusieurs années. Modulaire, opinionné juste ce qu'il faut, écosystème mature. FastAPI est une alternative valide en Python si votre équipe est plutôt data/IA.
Les briques transverses à installer dès le jour 1 :
Authentification. OIDC pour les professionnels (Pro Santé Connect, voir notre guide PSC) et FranceConnect+ pour les patients quand vous visez le catalogue MES. Voir notre guide intégration MES éditeurs.
Autorisation (RBAC + ABAC). Le RBAC par rôles (admin, médecin, IDE, AS, patient) est la base. L'ABAC y ajoute des règles contextuelles (un médecin n'a accès qu'aux dossiers de son service, un IDE qu'à ses patients du jour). Casbin ou OPA s'intègrent bien avec NestJS.
Audit log applicatif. Tracer toute action sur une donnée de santé : qui, quand, quoi, pourquoi. C'est exigé par le RGPD (art. 32 sécurité) et par la HAS pour les établissements. Stockage append-only, conservation 5 à 10 ans selon contexte.
Rate limiting et anti-bruteforce. Particulièrement sensible côté patient : un endpoint d'authentification non protégé est une porte d'entrée massive.
Validation stricte des inputs. Zod, class-validator ou Pydantic. Aucune confiance dans les données entrantes, même venant de clients mobiles signés.
Idempotency keys sur toutes les écritures sensibles. Évite les doubles débits, doubles dépôts au DMP, etc.
Couche domaine : organiser le métier
Une fois la couche API en place, la couche domaine doit refléter les concepts métier de la santé sans les noyer dans l'infrastructure. Quelques principes qu'on applique :
Bounded contexts. Séparer le domaine identité-patient (INS, identitovigilance), le domaine soin (actes, prescriptions, observations), le domaine documentaire (CDA, DMP) et le domaine administratif (facturation, planning). Ces domaines évoluent à des rythmes différents et ont des règles différentes.
Value objects pour les concepts forts. L'INS, le RPPS, un code LOINC, un code CIM-10 ne sont pas des string quelconques. Modélisez-les en value objects qui encapsulent la validation et la sérialisation.
Événements de domaine. Pour les actions métier significatives (création de dossier, signature d'acte, envoi au DMP), publiez un événement domaine. Permet de découpler les side-effects (audit, notifications, intégrations) du flux principal.
Pas de logique métier dans l'ORM. Les entités ORM sont des sacs de données. La logique métier vit dans des services domaine ou des modèles DDD.
Couche intégrations : isoler les systèmes externes
Les intégrations e-santé (DMP, MSSanté, PSC, INSi, FHIR, DPI hospitalier) sont nombreuses, hétérogènes et capricieuses. Les principes :
- Adapter pattern systématique. Chaque intégration externe est un adapter qui expose une interface stable au domaine. Le jour où l'API DMP change ou où l'opérateur MSSanté est remplacé, vous ne réécrivez pas la moitié du code.
- Circuit breakers sur tous les appels sortants. Une intégration qui tombe ne doit pas faire tomber votre app.
- Async par défaut sur les flux non interactifs. Un dépôt DMP, un envoi MSSanté, une publication FHIR : queue + worker, pas en synchrone dans la requête HTTP.
- Replay et idempotence : tout message dans la queue doit pouvoir être rejoué sans effet de bord.
- Logs structurés avec corrélation ID pour pouvoir tracer un flux de bout en bout dans les outils d'observabilité.
Voir nos guides détaillés sur HL7 FHIR en France et l'API annuaire santé / INS pour le détail des intégrations principales.
Couche edge : CDN, WAF, rate limiting
Devant l'API, une couche edge protège et accélère. Trois éléments :
- CDN pour les assets statiques (images publiques, JS bundle). Cloudflare, Bunny, ou natif AWS CloudFront. Pas pour les données de santé.
- WAF : règles OWASP Top 10, bot detection, geo-blocking si pertinent. Cloudflare WAF ou AWS WAF, configurés finement.
- Rate limiting global en complément du rate limiting applicatif. Ceinture et bretelles.
Sur les flux serveur-à-serveur (intégrations partenaires), privilégier mTLS pour authentifier les pairs au niveau transport.
Couche clients : web, mobile, intégrations
Le frontend web part en général sur Next.js avec rendu hybride (SSR + SSG selon les pages). Pour les apps métier hospitalières, on choisit souvent une SPA pure parce que le SEO n'est pas un sujet et que l'isomorphisme ajoute de la complexité.
Pour les apps mobiles, on a couvert la stack en détail dans notre REX React Native médical.
Pour les intégrations tierces (un éditeur partenaire qui consomme votre API), versionnez vos endpoints et publiez un OpenAPI à jour. Aucune intégration ne doit reposer sur de la rétro-ingénierie.
Observabilité avec scrubbing PHI
L'observabilité est le talon d'Achille classique de la conformité e-santé. Sentry, Datadog, Logtail, NewRelic : tous ces outils sont précieux mais ne sont pas hébergés en France et certainement pas HDS. Donc aucune donnée de santé identifiante ne doit y arriver.
Les règles qu'on applique :
- Wrapper de logs qui scrubbe par défaut tous les champs sensibles (
nir,ins,nom,prenom,dateNaissance, etc.). - Pas de payload complet dans les traces APM : seulement des identifiants techniques (UUID interne, IDs de ressources), jamais de contenu métier.
- Métadonnées techniques OK : codes HTTP, durées, tags de service. Tout ce qui ne réidentifie pas un patient.
- Sentry breadcrumbs : nettoyés via
beforeBreadcrumb. - Sampling agressif sur les traces complètes pour limiter le volume.
- Logs sensibles (audit applicatif, données réelles) dans une stack interne HDS (Loki, Elasticsearch self-hosted en HDS).
Cette double stack — observabilité technique externe + audit interne HDS — est la combinaison qu'on retrouve sur la plupart des projets matures.
Résilience : RPO, RTO et continuité
La résilience est un sujet souvent traité tard, à tort. Les engagements à documenter dès le début :
- RPO (Recovery Point Objective) : combien de minutes de données pouvez-vous perdre en cas d'incident ? Pour de l'e-santé, on vise 5 à 15 minutes maximum, ce qui implique des sauvegardes continues (PITR sur Postgres) et de la réplication.
- RTO (Recovery Time Objective) : combien de temps pour reprendre le service ? 1 à 4 heures pour la plupart des cas. Pour une app critique de service hospitalier, viser 30 minutes.
- Sauvegardes immuables : essentielles face aux ransomwares. Object Lock S3 ou équivalent, conservation distincte de la prod.
- Bascule géographique : pour les apps avec engagement SLA fort, prévoir une bascule entre régions HDS.
- Tests de bascule annuels minimum : un PCA non testé ne sert à rien le jour où on en a besoin.
Pièges et retours terrain
Quelques erreurs récurrentes sur les architectures e-santé :
Concevoir l'architecture sans avoir lu le référentiel HDS. Le référentiel HDS 2024 a renforcé certaines exigences (PRA, journalisation). Lisez-le avant le premier diagramme.
Mutualiser les environnements. Pas de prod et pré-prod sur le même cluster, pas de bases partagées. Isolation forte y compris pour le réseau.
Utiliser des services managés américains pour les données. AWS Lambda fonctionne bien et il est en HDS sur Paris, mais des services comme Cognito ou DynamoDB ne sont pas HDS partout : vérifier au cas par cas.
Stocker les NIR en clair. Y compris dans les logs, dans les exports, dans les events Kafka. Le NIR est l'un des champs les plus sensibles, son stockage doit être chiffré applicatif et scrubbé partout ailleurs.
Logs en clair envoyés à Datadog/Sentry. Voir section observabilité. Le scrubbing doit être en amont, pas dans les outils tiers.
Ignorer le PCA. Le jour de l'incident, un PCA documenté et testé fait toute la différence entre "incident résolu en 2h" et "incident sur la une des journaux pendant 3 jours".
Sous-investir le CI/CD. Beaucoup d'équipes mettent un pipeline minimal et se concentrent sur l'app. Le CI/CD est l'angle d'attaque principal des supply chain attacks. Investissez du temps dès le début.
FAQ — Architecture technique e-santé
Quelle taille d'équipe pour opérer cette architecture ? Pour un MVP en production : 3-4 développeurs full-stack avec un DevOps temps partiel. Pour un produit mature multi-clients : 6-10 personnes incluant un SRE dédié.
Combien coûte la stack en infra par mois ? Pour un MVP en production : 800 € à 2000 €/mois côté hébergeur HDS (PostgreSQL managé, K8s, S3, traffic). Pour une app à plusieurs milliers d'utilisateurs : 5000 € à 15 000 €/mois.
Faut-il du Kubernetes dès le début ? Pas obligatoire. Pour un MVP, des services managés (Heroku-like sur OVHcloud, ECS sur AWS) suffisent souvent. K8s devient pertinent au-delà de 10-15 services ou si vous opérez plusieurs environnements clients.
PostgreSQL ou MongoDB ? PostgreSQL pour 95 % des cas e-santé. Le relationnel s'adapte mieux aux exigences de cohérence et d'audit. MongoDB peut faire sens en complément pour des cas d'usage documentaires (logs cliniques bruts, éphémérides).
Comment gérer les migrations sans interruption ? Patterns standards : expand-and-contract, deux phases (déployer la nouvelle version qui supporte ancien et nouveau schéma, puis migrer, puis nettoyer). Outils : Flyway, Liquibase, ou les migrations natives Prisma/TypeORM.
Faut-il publier une API FHIR native ? Si vous échangez avec l'écosystème institutionnel (hôpitaux, ANS, éditeurs SIH), oui. FHIR R4 ou R5 selon vos partenaires. Sinon, une API REST classique avec sérialisation FHIR sur certains endpoints suffit.
Comment auditer son architecture HDS ? Audit interne annuel + audit externe par un tiers tous les 2-3 ans. Périmètre : conformité au référentiel HDS 2024, gestion des accès, journalisation, PCA/PRA. Conservez tous les rapports : ils servent en certification.
IA / LLM dans une app e-santé : quelle architecture ? Si vous appelez des LLM externes (OpenAI, Anthropic), ne pas envoyer de PHI dans les prompts sans accord HDS spécifique. Pour des cas d'usage internes sensibles, déployer des modèles open source (Llama, Mistral) sur infra HDS, ou utiliser les offres dédiées des hyperscalers (Azure OpenAI avec engagement HDS).
Aller plus loin
Une bonne architecture e-santé, c'est avant tout une stack standard bien posée + les exigences spécifiques (HDS, RGPD santé, audit, intégrations) intégrées dès le début. La complexité vient moins des composants que des règles à appliquer à chacun. Le travail le plus important est dans le cadrage : quelles données traitez-vous, sous quelle base légale, avec quelles intégrations, sous quels SLAs.
Si vous portez un projet e-santé qui doit poser des fondations techniques solides, parlons de votre projet. On peut auditer une archi existante, cadrer une nouvelle stack, ou intervenir comme CTO-as-a-Service pour structurer votre équipe technique.