Une startup du secteur médical m'a appelé début 2023. Des fondateurs sympas, un budget correct, un brief clair : formulaires d'admission de patients, planification de rendez-vous, peut-être un widget de télésanté plus tard. « Nous utilisons WP Engine », m'a dit le CTO. Je lui ai demandé si WP Engine avait signé leur BAA. Long silence. « C'est quoi un BAA ? »
C'est là que réside le problème, pas dans le code, pas dans la pile de plugins, mais dans la traçabilité administrative que la plupart des développeurs ne lisent jamais et que la plupart des hébergeurs évitent discrètement.
Voici le truc : la conformité HIPAA n'est pas une fonctionnalité qu'on active. C'est un cadre juridique, et le Business Associate Agreement est le contrat qui fait de votre fournisseur d'hébergement une partie formelle de ce cadre. Sans un BAA signé, peu importe si votre serveur exécute TLS 1.3 et que vous avez chiffré tous les champs de la base de données. Vous restez exposé. Vos clients aussi.
Laissez-moi vous expliquer ce que je sais réellement sur les plateformes qui signeront en 2026, et plus important encore, lesquelles disent les bonnes choses mais refusent de signer.
---
Ce qu'un BAA est réellement (et ce qu'il n'est pas)
Un Business Associate Agreement est un contrat en vertu de la HIPAA Privacy Rule qui lie un fournisseur à des obligations spécifiques concernant les informations de santé protégées (Protected Health Information, PHI). Lorsque vous hébergez un site de santé, votre fournisseur d'hébergement accède aux PHI, même si c'est seulement au niveau de l'infrastructure. Cela en fait un Business Associate. Point final.
Ce que le BAA ne fait pas, c'est vous rendre conforme automatiquement. Je vois cette incompréhension constamment. Le BAA signifie que l'hébergeur accepte sa part de responsabilité et s'engage à respecter des mesures de sauvegarde. Votre couche applicative, vos formulaires, vos plugins WordPress, votre journalisation, c'est toujours votre responsabilité.
Seahawk a eu un projet en 2022 pour un groupe de physiothérapie basé aux États-Unis qui gérait un site WordPress. Le client avait un BAA avec son fournisseur de messagerie (bien), son fournisseur de dossiers médicaux électroniques (évidemment), mais rien avec son hébergeur web. Son site collectait des données de symptômes via Gravity Forms. Chaque soumission était envoyée par email à un compte Gmail. Trois violations distinctes dans un seul workflow. Nous l'avons démêlé en environ six semaines.
---
Les hébergeurs qui vont réellement signer en 2026
AWS, GCP, et Azure, Les Options Sérieuses
Si vous avez besoin d'un BAA et vous avez besoin de certitude, les hyperscalers sont votre réponse. Tous les trois, Amazon Web Services, Google Cloud Platform, et Microsoft Azure, proposent des BAA et maintiennent des listes de services éligibles à la HIPAA.
AWS est ce que j'utilise le plus souvent. Le BAA couvre une gamme solide de services : EC2, RDS, S3, CloudFront, Lambda, et plus encore. De manière critique, pas chaque service AWS n'est éligible. DynamoDB est sur la liste ; pas tous les services expérimentaux le sont. Vous devez vérifier la page des services éligibles actuels avant d'architecturer quoi que ce soit.
Le BAA de GCP couvre BigQuery, Cloud SQL, Compute Engine, et Cloud Storage, entre autres. Azure a l'adoption entreprise la plus large dans le secteur de la santé, leur BAA et documentation de conformité sont matures, et si votre client est déjà dans l'écosystème Microsoft (ce que sont la plupart des organisations de santé entreprise), Azure a souvent du sens organisationnel.
Le piège avec ces trois : vous n'obtenez pas de WordPress géré. Vous obtenez de l'infrastructure. Quelqu'un doit construire et maintenir la stack, les mises à jour du système d'exploitation, la configuration WAF, les sauvegardes, le chiffrement au repos et en transit. Chez Seahawk, nous avons utilisé AWS avec une instance EC2 renforcée exécutant Nginx, PHP-FPM, et MySQL pour des clients du secteur de la santé. Ça fonctionne. C'est aussi beaucoup plus de surcharge opérationnelle qu'une simple connexion WP Engine.
Kinsta, Oui sous Certaines Conditions
Kinsta fonctionne sur GCP. Ils proposent la signature de BAA pour les clients sur leurs plans de niveau supérieur (Business 1 et au-dessus, à ma dernière vérification). C'est important parce que Kinsta est véritablement un excellent hébergement WordPress géré. Rapide. Fiable. De bons environnements de staging.
Mais, et c'est important de le souligner, la couverture BAA de Kinsta est quelque peu plus étroite que si vous alliez directement chez GCP vous-même. Vous dépendez des contrôles internes de Kinsta ainsi que de ceux de GCP. Pour de nombreux projets WordPress dans le secteur sanitaire, c'est acceptable. Pour tout ce qui touche à des données très sensibles en volume, je voudrais comprendre exactement ce que dit leur documentation de sécurité avant de m'engager.
Cloudways, Non
Cloudways est populaire dans le monde des agences. Un bon rapport prix-performance. Nous l'avons utilisé sur des dizaines de projets non sensibles. Mais à ma dernière vérification, Cloudways n'offre pas de BAA HIPAA. Ils fonctionnent même sur AWS et GCP en dessous, ce qui est légèrement ironique. La couche gérée introduit une incertitude qu'ils ne sont pas prêts à couvrir contractuellement à des fins HIPAA.
Pantheon, Non (pour la plupart des forfaits)
Pantheon est excellent pour les agences Drupal et WordPress. La conformité HIPAA n'est pas leur marché. Ils ont été clairs à ce sujet. Ne vous laissez pas tromper par l'image de marque d'entreprise.
WP Engine, Non
Je sais. Ils disposent de documentation de conformité. Ils parlent de sécurité. Ils ne signeront pas de BAA HIPAA. Leurs conditions d'utilisation interdisent explicitement de stocker des PHI sur leur plateforme. Cela les disqualifie pour tout véritable cas d'usage dans le secteur de la santé. La startup que j'ai mentionnée en haut de cet article ? C'est exactement là qu'elle en était.
Liquid Web / Nexcess, Possible, avec des réserves
Liquid Web a proposé un hébergement géré conforme à la HIPAA avec signature de BAA, généralement sur leurs produits de serveurs dédiés ou VPS plutôt que sur des plans partagés. Cela vaut la peine d'avoir une conversation directe avec leur équipe commerciale. Leur posture en matière de conformité s'est améliorée. Mais je voudrais avoir le BAA en main avant de construire quoi que ce soit.
---
Ce dont votre pile WordPress a besoin au-delà du BAA
Le BAA est la fondation, pas le bâtiment. Voici ce qui doit réellement se passer au niveau de la couche applicative pour un site WordPress adjacent à la HIPAA.
Formulaires et collecte de données
- Gravity Forms avec la bonne configuration peut être utilisé, mais Gravity Forms natif stocke les soumissions dans la base de données WordPress par défaut. Pour du PHI, vous devez soit désactiver le stockage en base de données et diriger les données de manière sécurisée vers une destination conforme à la HIPAA, soit utiliser leur add-on Encrypted Fields avec prudence.
- Cognito Forms et FormAssembly proposent tous les deux des niveaux conformes à la HIPAA avec des BAA. Si le formulaire est le point principal de collecte de données, ces solutions sont souvent plus simples que de se battre avec GF.
- Ne jamais, au grand jamais, utiliser de plugins de formulaire de contact gratuits qui envoient des données à des serveurs tiers sans vérifier leur posture en matière de conformité.
Celui-ci en tue plus d'un. Votre site WordPress envoie probablement des emails via wp_mail(), qui par défaut utilise PHP mail ou un plugin SMTP connecté. Gmail standard, Mailchimp standard, SendGrid standard, aucun d'entre eux ne signe un BAA HIPAA aux niveaux d'entrée.
Paubox est celui que je recommande régulièrement pour les petits et moyens clients du secteur sanitaire. Email conforme à la HIPAA, BAA inclus, tarification transparente. Google Workspace propose aussi un BAA pour ses clients du secteur sanitaire, mais cela exige un forfait spécifique et un processus de demande formel, cela ne s'applique pas à un compte Google standard.
Plugins et intégrations tierces
Chaque plugin qui établit une connexion, chaque script d'analyse, chaque widget de chat en direct, tout cela touche potentiellement aux PHI selon les données qui se trouvent sur la page. Faites un vrai audit. J'utilise Query Monitor pour identifier ce qui fait des requêtes externes, puis je fais un recoupement avec la documentation de conformité de chaque fournisseur.
HubSpot signera un BAA. Intercom ne le fera pas (aux niveaux standard). Hotjar ne devrait presque certainement pas s'exécuter sur un site santé sans un exercice de cadrage très minutieux.
---
Comment obtenir réellement un BAA signé
C'est plus procédural que technique, mais j'ai vu des projets stagner à cette étape.
- Identifiez chaque fournisseur qui touche ou pourrait toucher aux PHI, l'hébergeur, le CDN, l'email, les formulaires, l'analyse, le chat d'assistance, le fournisseur de sauvegarde.
- Demandez la documentation BAA auprès de l'équipe ventes ou conformité de chaque fournisseur. Ne supposez rien. Obtenez-le par écrit.
- Examinez le périmètre, un BAA qui ne couvre que certains services ou certains types de données doit être compris avant que vous le signiez.
- Stockez les accords signés quelque part où l'équipe juridique de votre client peut y accéder. Pas seulement dans votre boîte de réception.
- Révisez annuellement, les fournisseurs changent leurs politiques, les services sont abandonnés, et un BAA qui couvrait votre stack en 2024 pourrait avoir des lacunes en 2026.
Les directives du HHS sur les Business Associates sont en fait lisibles. À consacrer trente minutes si vous êtes nouveau dans ce domaine.
---
Le problème du CDN dont personne ne parle
Vous avez réglé votre hébergeur. Vous avez un BAA. Vous avez sécurisé la couche application. Puis vous mettez Cloudflare devant.
Cloudflare signera un BAA, mais uniquement sur son plan Enterprise, qui commence à un tarif qui l'exclut pour la plupart des petits clients du secteur de la santé. Les niveaux gratuit et Pro ? Pas de BAA. Ce qui signifie que Cloudflare décrypte et inspecte techniquement votre trafic HTTPS sans BAA en place, sur un site qui peut contenir des PHI en transit.
Pour les projets plus petits, j'ai contourné cela en utilisant AWS CloudFront (éligible BAA) comme couche CDN quand le site est déjà sur EC2 ou derrière un Application Load Balancer. C'est moins glamour qu'un tableau de bord Cloudflare mais c'est propre du point de vue de la conformité.
---
Ce que je construirais réellement en 2026
Si un client du secteur de la santé me contactait demain avec une exigence WordPress, voici à peu près comment j'architecturerais la solution :
- Hébergement : AWS EC2 (avec un BAA signé) exécutant une pile LEMP renforcée, ou Kinsta Business avec leur BAA en main
- Email : Paubox pour les emails transactionnels et destinés aux fournisseurs
- Formulaires : FormAssembly ou Gravity Forms avec le stockage en base de données désactivé et l'acheminement des envois chiffré
- CDN : AWS CloudFront, pas Cloudflare gratuit/Pro
- Analytics : Matomo auto-hébergé sur la même infrastructure couverte par un BAA, pas de Google Analytics pour tout ce qui pourrait avoir des PHI dans l'URL ou les paramètres
- Sauvegardes : AWS S3 (conforme à la clause BAA) avec chiffrement côté serveur
Est-ce plus cher qu'une construction WordPress standard ? Oui. Est-ce plus complexe sur le plan opérationnel ? Aussi oui. Mais l'alternative, c'est un client face à un processus de notification de violation HIPAA, des amendes potentielles à partir de 100 dollars par violation par jour, et une conversation très inconfortable sur la raison pour laquelle son développeur n'a jamais mentionné tout cela.
---
FAQ
Est-ce que « l'hébergement conforme à la HIPAA » a une valeur légale ?
Non. C'est une formule marketing. Ce qui a une valeur légale, c'est un BAA signé. N'importe quel hébergeur peut se dire conforme à la HIPAA, prêt pour la HIPAA, ou quelque chose du genre. Sans BAA, ces mots sont purement décor. Posez toujours la question précise : « Signerez-vous un Business Associate Agreement avec nous ? »
Mon site a-t-il besoin d'un BAA s'il ne contient qu'un formulaire de contact ?
Si le formulaire de contact collecte des informations qui pourraient constituer des PHI, des symptômes, des diagnostics, des raisons de rendez-vous, n'importe quoi lié à l'identité et au statut de santé d'un patient, alors oui, chaque fournisseur de cette chaîne de données devrait avoir un BAA. Un formulaire générique « prendre un rendez-vous » qui collecte uniquement le nom, le téléphone et l'heure préférée est une zone plus grise, mais je penserais quand même à obtenir le BAA.
Puis-je utiliser WordPress.com pour un site de santé ?
WordPress.com (la plateforme hébergée, pas le logiciel WordPress auto-hébergé) n'offre pas de BAA HIPAA. Point final. C'est différent de WordPress auto-hébergé sur une infrastructure conforme. Le logiciel est correct. La plateforme hébergée n'est pas appropriée pour les PHI.
Que se passe-t-il si un prestataire que j'utilise est acquis et le nouveau propriétaire abandonne le BAA ?
C'est un risque réel et je l'ai vu se produire avec des outils SaaS plus petits. Votre BAA devrait avoir des clauses de résiliation qui se déclenchent si le fournisseur ne peut plus respecter les obligations HIPAA. Quand vous recevez un e-mail d'annonce d'acquisition, ne le jetez pas, vérifiez si les engagements en matière de conformité sont maintenus sous la nouvelle entité.
La HIPAA ne concerne-t-elle que les États-Unis ?
Oui, HIPAA est une loi fédérale américaine. Mais si vous construisez pour des clients du secteur de la santé au Royaume-Uni ou dans l'UE, les équivalents, les normes NHS Digital, le Data Security and Protection Toolkit, et le RGPD appliqué aux données de santé, ont des exigences similaires concernant les accords avec les sous-traitants de données. Le cadre diffère, la logique non.
---
La plupart des développeurs, s'ils sont honnêtes, ne pensent pas au BAA que jusqu'à ce que quelqu'un le demande. À ce moment-là, soit tout va bien (vous avez eu de la chance), soit vous retrofittez une pile sous la pression avec un client nerveux au téléphone.
Mieux vaut connaître le paysage avant de commencer le projet que de réaliser à mi-parcours d'une implémentation que votre hébergeur ne signera pas le seul document qui compte vraiment.
Lectures recommandées : Sécurité headless vs WordPress en 2026 : pourquoi Next.js et Astro, Next.js, et headless.