Architecture serverless pour la santé numérique : choix d'infrastructure qui comptent

Construire une application de santé numérique en 2026 ne ressemble plus à ce que les architectes informatiques connaissaient il y a cinq ans. Les coûts d'infrastructure variables, les exigences réglementaires européennes et arabes, l'attente d'un time-to-market court et la nécessité de fonctionner dans plusieurs juridictions imposent des choix de conception qui pèsent lourd dès le premier mois de développement. Pour DossiMed, nous avons retenu une architecture entièrement serverless organisée autour de trois piliers techniques. Cet article expose ces choix et leurs conséquences pratiques, sans entrer dans les détails de configuration interne.

Pourquoi le serverless en santé numérique

L'argument le plus visible du serverless est financier : on ne paie que les ressources réellement consommées. Pour une plateforme santé qui sert des utilisateurs en pic le matin (rappel de prise) et le soir (consultation du dossier), avec des plages quasi désertes la nuit, ce modèle est directement aligné avec la courbe d'usage. Une infrastructure dimensionnée en pic 24 h sur 24 gaspille structurellement.

Mais la raison plus profonde est ailleurs.

Le troisième argument est le time-to-market. Déployer une nouvelle fonctionnalité demande de pousser une fonction stateless de quelques dizaines de lignes, pas de réviser un cluster Kubernetes. Pour une startup santé qui doit converger sur un produit qui marche avant d'être à court de runway, c'est un avantage décisif.

Pilier 1 — La base de données comme première couche de sécurité

L'erreur la plus fréquente dans les projets santé est de protéger les données au niveau de l'application. Le code applicatif vérifie que tel utilisateur peut lire tel document, et l'on espère qu'aucun chemin oublié ne contourne ce contrôle. C'est insuffisant. Une seule fonction laissée sans vérification d'autorisation suffit à exposer les dossiers de tous les utilisateurs.

Notre choix : placer la sécurité d'accès directement dans le moteur de base de données, via le mécanisme de Row Level Security (RLS) de PostgreSQL. Concrètement, chaque table métier est protégée par une politique qui s'exécute automatiquement à chaque requête, à un niveau plus profond que toute logique applicative. La règle est simple : un utilisateur ne peut lire ou modifier que les lignes qu'il possède. Cette règle est portée par la base elle-même, pas par l'application.

L'effet pratique est radical. Si un développeur introduit demain une nouvelle fonction qui interroge la base sans vérifier l'identité de l'appelant, la base de données rejette les lignes qui n'appartiennent pas à l'utilisateur. La sécurité ne dépend plus de la mémoire des développeurs ni de la qualité de la revue de code.

Pilier 2 — Les fonctions edge comme couche de logique sensible

Toute la logique qui nécessite des secrets vit dans des fonctions edge serverless écrites en TypeScript. Aucune clé ne descend jamais sur le téléphone de l'utilisateur. Le client mobile ne voit que des points d'entrée HTTP qui exigent un JWT utilisateur valide.

Les fonctions edge couvrent l'ensemble de la logique sensible :

• OCR et extraction structurée des documents médicaux
• Génération du plan de traitement
• Envoi des rappels par notification
• Escalade vers les canaux conversationnels (WhatsApp, voix)
• Validation des webhooks tiers et signatures cryptographiques
• Gestion des achats in-app
• Suppression complète de compte (droit à l'effacement RGPD)
• Génération des liens de partage médecin avec token éphémère

Cette séparation a deux conséquences importantes. D'abord, la rotation de secrets devient indolore : quand un fournisseur tiers demande de changer une clé API, on met à jour la variable d'environnement de la fonction edge — aucune mise à jour client, aucun déploiement Play Store ou App Store, aucune base utilisateur fragmentée entre versions.

Ensuite, l'audit de sécurité se concentre. La surface des fonctions sensibles est petite, traçable, isolée. Quand un acheteur ou un auditeur veut comprendre où sont les risques, il regarde un dossier functions/ au lieu de chercher dans des dizaines de milliers de lignes de code Flutter ou Web.

Pilier 3 — Le stockage privé avec accès cryptographiquement borné

Les images de documents médicaux et les pièces jointes au dossier patient sont stockées dans des buckets privés, sans aucune URL publique. L'accès se fait exclusivement par signed URLs à durée de vie courte, générées côté serveur à la demande.

La convention de chemin est elle-même structurée pour empêcher les fuites latérales : chaque ressource vit sous un chemin qui commence par l'identifiant de l'utilisateur propriétaire. Couplée aux politiques de storage, cette convention garantit qu'un utilisateur ne peut, par construction, écrire ou lire que dans son propre dossier.

Pour les médecins qui consultent un dossier partagé, le flux est différent : ils ouvrent un lien qui contient un token éphémère. Le serveur web vérifie le hash de ce token, applique les restrictions définies par le patient (catégories de documents, période, spécialité), génère des signed URLs temporaires pour chaque ressource consultable, et rend la page. Le médecin ne voit jamais une URL persistante du document.

Une juridiction d'hébergement adéquate

Le serveur principal de DossiMed est hébergé en Suisse, dans la région Europe centrale. Ce choix répond à plusieurs contraintes simultanées.

Décision d'adéquation européenne. La Suisse bénéficie d'une décision d'adéquation de la Commission européenne au sens de l'article 45 du RGPD. Les transferts de données depuis l'Union vers la Suisse sont assimilés à des transferts intra-UE et ne nécessitent pas de mécanisme contractuel complémentaire — un avantage significatif sur les régions américaines, qui imposent depuis l'arrêt Schrems II la signature de Clauses Contractuelles Types.

Alignement avec la nLPD. La nouvelle Loi fédérale suisse sur la protection des données, entrée en vigueur le 1ᵉʳ septembre 2023, est largement alignée avec le RGPD. Une plateforme conforme au RGPD est conforme à la nLPD — construire en Suisse signifie respecter le seuil le plus exigeant.

Optimum géographique MENA + Europe. La latence moyenne depuis Zurich vers la France, la Belgique, l'Allemagne, l'Italie, l'Afrique du Nord et le Moyen-Orient reste excellente. Pour une application qui sert des marchés multilingues européens et MENA, c'est l'optimum géographique actuel.

Le pipeline asynchrone

Le traitement OCR + extraction structurée d'un document médical prend typiquement entre quelques secondes et une minute. Demander à l'utilisateur d'attendre, écran bloqué, est inacceptable en termes d'expérience.

Notre pattern fonctionne en trois temps :

1. Le client mobile téléverse l'image et écrit une ligne en base avec le statut pending
2. Il s'abonne en Realtime aux mutations de cette ligne
3. La fonction edge de traitement s'exécute en arrière-plan, puis écrit le résultat structuré en passant le statut à processed — le client reçoit l'événement et affiche immédiatement les données

Ce pattern, très simple à implémenter avec PostgreSQL et un canal Realtime, donne l'impression d'une application instantanée alors que le traitement réel est asynchrone. Il évite les long polls, les websockets custom et la gestion d'état distribuée — sources classiques de bugs dans les applications santé.

Multilinguisme natif au niveau infrastructure

Le multilinguisme dans les apps santé est rarement traité comme un sujet d'infrastructure. La plupart des produits se contentent de traduire l'interface utilisateur et considèrent le travail terminé. C'est une erreur lorsque l'on cible des marchés MENA et européens où la langue n'est pas accessoire mais centrale dans la confiance accordée à un outil de santé.

DossiMed traite le multilinguisme comme un paramètre architectural. Les communications sortantes — notifications, messages WhatsApp, scripts d'appel vocal — sont localisées au niveau du moteur, pas au niveau du client. La langue préférée de l'utilisateur est stockée en base et consommée par les fonctions edge qui choisissent le bon template, la bonne voix de synthèse, le bon sens d'écriture. Les modèles d'IA documentaire traitent indifféremment l'arabe, le français, l'anglais et leurs variantes régionales.

L'effet est qu'un utilisateur arabophone reçoit un appel vocal dans sa langue maternelle, avec une voix de synthèse adaptée, à partir d'un système qui n'a pas été pensé en monolingue puis traduit a posteriori.

La conformité par construction

La régulation européenne des données de santé impose un ensemble de droits et d'obligations que la plupart des équipes implémentent a posteriori, au coût d'un audit ou d'une mise en demeure. Les implémenter dès la conception est presque gratuit.

Notre discipline de conformité repose sur quelques règles simples :

• Chaque table métier expose les attributs de traçabilité minimaux (identifiant utilisateur, dates de création et de modification)
• Chaque suppression utilisateur déclenche une cascade complète vers les tables enfants
• Les buckets de stockage suivent la même convention de propriété par utilisateur
• Un export de toutes les données d'un utilisateur se résume à une requête JSON par table, plus la liste de ses fichiers

Cette discipline n'a pas été une réponse à un audit. Elle a été un principe de conception dès le premier jour — probablement le retour sur investissement le plus important que nous ayons fait sur le projet.

Ce qu'une architecture mature signale à un acheteur

Pour une équipe technique qui évalue une plateforme santé en vue d'une intégration ou d'une acquisition, certains signaux comptent davantage que les démos d'interface :

• La qualité et la cohérence des migrations SQL
• Le respect de la Row Level Security sur toutes les tables métier
• La séparation stricte client/serveur sans secret exposé côté mobile
• La portabilité du code vers n'importe quelle région cible
• L'absence de dette technique liée à l'historique de développement

Ces éléments racontent l'histoire d'une équipe qui a construit avec discipline.

DossiMed est édité par REC, une SUARL tunisienne totalement exportatrice. La plateforme est hébergée dans l'Union des juridictions adéquates au sens de l'article 45 du RGPD. Pour toute question commerciale ou de partenariat stratégique, écrivez à contact@dossimed.ai.