Quand un éditeur santé annonce « notre solution est HDS », il faut entendre derrière cette phrase une réalité plus exigeante que ce que le marketing laisse croire. La certification HDS (Hébergement de Données de Santé) délivrée par l'Agence du Numérique en Santé n'est pas un simple agrément géographique — « les serveurs sont en France » — mais un cadre normatif qui couvre une vingtaine d'exigences techniques et organisationnelles, dont la moitié sont vérifiées par audit terrain par un organisme accrédité COFRAC. Cet article décrit ce qu'un auditeur HDS examine réellement, et où les architectures que nous voyons régulièrement échouent. La première dimension auditée est la conformité RGPD santé renforcée — l'article 9 du règlement européen plus les obligations spécifiques du Code de la santé publique français. L'auditeur vérifie que la base légale du traitement est documentée, que les durées de conservation respectent les seuils réglementaires (20 ans après le dernier acte pour un dossier hospitalier, par exemple), que les droits patient sont effectivement exerçables (article L1111-7 : accès à son dossier et à l'historique des accès). Les éditeurs qui pensent que « être chez OVH HDS » suffit découvrent souvent à ce stade qu'il manque la moitié du dossier juridique. La pseudonymisation systématique des données est l'exigence technique la plus structurante. Nom, prénom, date de naissance et INS-NIA doivent être chiffrés au niveau colonne dans la base — pas seulement protégés par le chiffrement disque. L'argument typique « AES-256 sur le volume EBS, on est couverts » est rejeté : un attaquant qui obtient un dump applicatif via une injection SQL contourne le chiffrement disque sans difficulté. La bonne pratique combine pgcrypto avec des clés gérées dans Vault ou KMS, et des index sur des digests salés pour permettre la recherche. L'audit trail immuable est l'élément que l'auditeur examine en deuxième position. Chaque lecture, écriture ou export d'un dossier patient doit produire un événement signé, conservé deux à dix ans selon le contexte clinique. La technique éprouvée est le hash-chain append-only : chaque événement contient le hash du précédent, ce qui rend toute suppression ou modification immédiatement détectable par re-calcul de la chaîne. Postgres avec un trigger BEFORE INSERT qui calcule le hash et refuse les écritures hors séquence suffit techniquement ; le piège est de l'oublier sur les chemins administratifs (consoles d'admin DB, scripts de migration). La séparation par établissement est le troisième pilier. Quand une plateforme sert plusieurs structures (cliniques, EHPAD, cabinets), l'isolation ne peut pas être seulement applicative : l'auditeur demande à voir le mécanisme d'enforcement au niveau base. PostgreSQL Row Level Security est la solution canonique : `facility_id` sur chaque ligne, policy `USING` qui filtre selon une variable de session positionnée à chaque transaction. Le test prouvant l'isolation — un compte d'un établissement A qui tente d'accéder aux données d'un établissement B et reçoit un résultat vide — doit être automatisé dans la CI et présentable à l'auditeur. L'intégration au DMP via Interop'Santé est l'écueil technique le plus consommateur. L'authentification s'appuie sur des certificats X.509 signés par l'IGC-Santé, avec un échange en CDA-R2 dont le schéma rejette tout XML mal formé sans message d'erreur intelligible. ProSantéConnect — l'OIDC santé — requiert quant à lui une validation du certificat CPS au niveau matériel sur les postes de soin, ce qui se reproduit mal en environnement de test. La voie pragmatique est un proxy local (un petit service en Go ou Python) qui isole ces complexités du backend principal et qu'on peut mocker à l'unité. Les tests d'intrusion annuels sont la partie qu'on ne peut pas falsifier. Un pentest HDS sérieux dure deux à trois semaines, couvre l'application, l'infrastructure et — souvent oublié — les processus opérationnels (récupération d'un dossier par téléphone, prétexte client mystère). Les findings doivent être tracés dans un plan d'action avec dates de remédiation tenables ; un finding critique non corrigé après six mois est un signal qui fait échouer l'audit suivant. Compter une enveloppe de 8 à 15 k€ par exercice pour un éditeur santé de taille moyenne. Dernier point souvent négligé : la gestion de la continuité en cas de compromission. Il ne suffit pas d'avoir des sauvegardes — l'auditeur veut voir un plan de continuité testé, avec un RTO et un RPO documentés, des sauvegardes offline immuables (cassettes LTO ou snapshots S3 avec object-lock), et un exercice de restauration complet au moins annuel. Beaucoup d'éditeurs ont des sauvegardes mais n'ont jamais testé la restauration sous pression ; c'est exactement ce que l'auditeur cherche à exposer. La note de fin pour les éditeurs qui démarrent : viser HDS, c'est intégrer ces exigences au design du système, pas les ajouter en couche tardive. Une architecture pensée d'emblée avec pseudonymisation par défaut, RLS Postgres, audit hash-chaîné et intégrations santé encapsulées passe l'audit HDS sans drame ; une architecture pensée comme un SaaS standard auquel on rajoute « la conformité » dépense trois à cinq fois plus pour le même résultat, et garde la dette technique des années.