Votre patient clique sur « Formulaires Nouveau Patient » sur votre site WordPress. Six secondes passent. Le PDF se charge enfin. Il l'imprime, le remplit à la main, puis le renvoie par fax—parce que votre système d'accueil a été construit en 2014. Pendant ce temps, votre responsable informatique de conformité vient de découvrir que les données des patients transitent par trois plugins non sécurisés, et votre score Lighthouse mobile est de 34. Un cabinet d'orthopédie de taille moyenne du sud-est des États-Unis a fait face à ce scénario exact. Six mois plus tard : frontend Next.js, backend Payload CMS, formulaires d'accueil HIPAA-safe, et des scores Lighthouse de 94/99. Mais la vraie victoire n'était pas la vitesse—c'était les quatre points d'exposition HIPAA que nous avons fermés avant leur audit.

Table des matières

Cabinet de santé : migration WordPress vers Next.js + Payload CMS

Le point de départ : ce avec quoi nous avons travaillé

Le cabinet—appelons-le Southeastern Ortho (NDA, vous savez comment ça marche)—utilise WordPress depuis 2017. Leur configuration était typique d'un cabinet de santé qui a grandi de manière organique sans supervision technique particulière :

  • WordPress 6.2 avec 34 plugins (11 d'entre eux n'avaient pas été mis à jour depuis plus d'un an)
  • Hébergement partagé sur un forfait coûtant 29 $/mois
  • Contact Form 7 gérant les demandes des patients—sans chiffrement, sans accord BAA avec le prestataire d'hébergement
  • Formulaires PDF d'accueil que les patients devaient télécharger, imprimer, remplir à la main, puis envoyer par fax ou apporter aux rendez-vous
  • Temps de chargement des pages moyennant 6,8 secondes sur mobile
  • Score Lighthouse mobile : 38

Ce score Lighthouse n'est pas une coquille. Trente-huit. Le site avait des images héros non optimisées (l'une faisait 4,2 Mo en PNG), du CSS bloquant le rendu provenant de cinq plugins différents, et jQuery se chargeait trois fois en raison de conflits de plugins.

Mais le vrai problème n'était pas la performance. C'était le risque.

Ses formulaires de contact collectaient les noms, numéros de téléphone et parfois les descriptions de plaintes médicales des patients. Ces données transitaient par un plugin de formulaire non chiffré, étaient stockées dans une base de données WordPress sur un hébergement partagé, et sauvegardées sur un service sans accord d'associé commercial (BAA). Son responsable de conformité avait signalé cela, et son assureur responsabilité civile professionnelle posait des questions pointues.

Le brief

Le cabinet avait besoin de :

  1. Un site Web rapide et moderne reflétant la qualité de ses soins
  2. Des formulaires d'accueil des patients HIPAA-safe remplaçant le processus papier
  3. Un CMS que son responsable de bureau puisse mettre à jour sans appeler un développeur
  4. Une meilleure performance SEO (il perdait les classements de recherche locaux face à des cabinets plus récents)
  5. Tout cela sans se ruiner—c'est un cabinet médical, pas une startup technologique

Pourquoi Next.js et Payload CMS

Nous avons évalué plusieurs options d'architecture. Voici la comparaison honnête que nous avons présentée au client :

Option Avantages Inconvénients Coût estimé
Reconstruction WordPress (nouveau thème + plugins) Familier au personnel, coût initial plus bas Mêmes risques HIPAA, plafond de performance, dépendance aux plugins 15 000-25 000 $
Webflow + formulaires tiers Rapide à construire, bonne performance Options de conformité HIPAA limitées, coûts récurrents par siège, verrouillage du fournisseur 20 000-30 000 $
Next.js + Payload CMS Contrôle total, architecture HIPAA-safe, meilleure performance Investissement initial plus élevé, gestion d'hébergement requise 35 000-50 000 $
Next.js + Sanity Excellente expérience d'édition, bon écosystème La tarification de Sanity augmente avec l'utilisation, préoccupations concernant la gestion des informations de santé protégées avec un CMS hébergé dans le cloud 30 000-45 000 $

Nous avons recommandé Next.js avec Payload CMS, et voici pourquoi.

Next.js était le bon frontend

Next.js 14 (ce projet a commencé fin 2024, et nous utilisons maintenant la version 15) nous a donné exactement ce qu'un site de santé nécessite :

  • Génération statique pour les pages de contenu—biographies de médecins, descriptions de services, informations de localisation. Ces pages changent rarement, donc nous les pré-rendons au moment de la construction. Zéro calcul serveur au moment de la requête signifie un TTFB rapide.
  • Server Components pour le contenu dynamique—disponibilité des rendez-vous, articles de blog, et la logique des formulaires d'accueil bénéficient tous du rendu côté serveur sans expédier du JavaScript inutile au client.
  • Optimisation d'images prête à l'emploi—next/image avec conversion automatique WebP/AVIF a remplacé ces PNG de 4 Mo par des images correctement dimensionnées et chargées paresseusement.
  • Middleware pour les en-têtes de sécurité—nous utilisons le middleware Next.js pour définir des en-têtes CSP stricts, HSTS, et autres en-têtes de sécurité que les auditeurs HIPAA adorent voir.

Si vous êtes curieux de connaître notre approche, nous avons documenté nos capacités de développement Next.js plus en détail.

Payload CMS était le bon backend

Nous avons choisi Payload CMS 3.0 par rapport à d'autres options headless pour plusieurs raisons spécifiques aux soins de santé :

Auto-hébergement par conception. Payload fonctionne sur votre propre infrastructure. C'est non-négociable pour HIPAA. Lorsque vous gérez des informations de santé protégées (PHI), vous devez savoir exactement où vivent vos données, qui y a accès, et être capable de signer un accord BAA avec votre prestataire d'infrastructure. Les plates-formes CMS hébergées dans le cloud comme Contentful ou Sanity stockent les données sur leurs serveurs—et bien que certaines offrent la conformité HIPAA aux niveaux entreprise, le coût est généralement 3 à 5 fois supérieur à ce que vous paieriez pour auto-héberger Payload sur un prestataire éligible HIPAA.

Natif TypeScript. La configuration de Payload est simplement du TypeScript. Cela signifie que nos modèles de contenu, réponses d'API, et types frontaux partagent tous une source unique de vérité. Lorsque le responsable du bureau ajoute un nouveau champ pour « numéro de préautorisation d'assurance » au formulaire d'accueil, votre frontend le saura immédiatement grâce aux types générés.

Contrôle d'accès intégré. Le contrôle d'accès au niveau des champs de Payload signifiait que nous pouvions créer des rôles où la personne du marketing pouvait éditer les articles de blog et les pages de services, mais ne pouvait pas toucher aux données d'accueil des patients. Le responsable du bureau pouvait afficher les soumissions d'accueil mais ne pouvait pas modifier la structure du formulaire. Cette granularité compte lorsque vous documentez les contrôles d'accès pour la conformité.

Texte enrichi fait correctement. Payload utilise Lexical (anciennement Slate) pour le texte enrichi, et l'expérience d'édition est genuinely bonne. Le responsable du bureau de notre client, qui utilisait WordPress depuis des années, s'est senti à l'aise dans le panneau d'administration de Payload après une seule session de formation de 45 minutes.

Nous travaillons régulièrement avec Payload et d'autres plates-formes CMS headless—vous pouvez en voir plus sur notre approche de développement CMS headless.

Considérations HIPAA dans une architecture headless

Je dois clarifier quelque chose : aucune pile technologique n'est « conforme HIPAA » en soi. La conformité HIPAA est une pratique organisationnelle, pas une fonctionnalité logicielle. Ce qu'une pile technologique peut être, c'est « HIPAA-safe »—ce qui signifie qu'elle ne présente pas de risque inutile et soutient les mesures de sauvegarde administratives, physiques et techniques que HIPAA exige.

Voici ce que nous avons mis en œuvre :

Infrastructure

  • Hébergement : AWS avec un accord BAA signé. Nous avons utilisé ECS Fargate pour le conteneur Payload CMS et déployé le frontend Next.js sur Vercel (qui ne gère pas les PHI—distinction importante).
  • Base de données : Amazon RDS PostgreSQL avec chiffrement au repos (AES-256) et chiffrement en transit (TLS 1.2+). Payload 3.0 supporte nativement Postgres, ce qui était une grande raison pour laquelle nous avons attendu la v3.
  • Stockage de fichiers : S3 avec chiffrement côté serveur, politiques de bucket restrictives limitant l'accès, et versioning activé pour les pistes d'audit.

Flux de données pour l'accueil des patients

C'est là que l'architecture devient intéressante. Le formulaire d'accueil des patients vit sur le frontend Next.js, mais nous ne envoyons jamais de PHI à travers l'infrastructure de Vercel.

Navigateur patient → HTTPS → Route API (Next.js sur Vercel) → AUCUNE PHI stockée ici
                                    ↓
                           API Gateway AWS (avec WAF)
                                    ↓
                           Fonction Lambda (valide, chiffre)
                                    ↓
                           API Payload CMS (sur ECS Fargate)
                                    ↓
                           RDS PostgreSQL (chiffré au repos)

La route API Next.js agit comme un proxy fin. Elle valide la structure de la requête (jeton CSRF, limitation de débit, validation basique des champs) mais ne stocke ni ne consigne aucune PHI. Le traitement réel des données s'effectue entièrement dans les services éligibles HIPAA d'AWS.

Détails du chiffrement

Nous avons implémenté le chiffrement au niveau des champs pour les données les plus sensibles. Les fragments de numéro de sécurité sociale des patients (les 4 derniers), les ID d'assurance, et les descriptions de plaintes médicales sont chiffrés au niveau de l'application en utilisant AES-256-GCM avant même d'atteindre la base de données. Cela signifie que même si quelqu'un accédait à la base de données, il verrait des blobs chiffrés pour les champs sensibles.

// Version simplifiée de notre hook de chiffrement au niveau des champs dans Payload
import { encrypt } from '../lib/crypto';

const PatientIntake: CollectionConfig = {
  slug: 'patient-intake',
  hooks: {
    beforeChange: [
      async ({ data }) => {
        if (data.ssnLastFour) {
          data.ssnLastFour = await encrypt(data.ssnLastFour);
        }
        if (data.medicalComplaint) {
          data.medicalComplaint = await encrypt(data.medicalComplaint);
        }
        return data;
      },
    ],
  },
  access: {
    read: ({ req: { user } }) => {
      return user?.role === 'office-admin' || user?.role === 'provider';
    },
    create: () => true, // Soumission de formulaire public
    update: ({ req: { user } }) => user?.role === 'office-admin',
    delete: () => false, // Politique de rétention - pas de suppressions via CMS
  },
  fields: [
    // ... définitions de champs
  ],
};

Enregistrement d'audit

Chaque accès aux données d'accueil des patients est enregistré—qui l'a consulté, quand, et à partir de quelle adresse IP. Nous avons construit un plugin Payload personnalisé qui écrit dans une table de journal d'audit séparé. Cette table est à ajout uniquement ; même les utilisateurs administrateurs ne peuvent pas modifier ou supprimer les entrées. Lors de l'évaluation annuelle des risques HIPAA du cabinet, cette piste d'audit a été spécifiquement signalée comme un point fort.

Cabinet de santé : migration WordPress vers Next.js + Payload CMS - architecture

La refonte du formulaire d'accueil des patients

L'ancien processus : Le patient télécharge un PDF de 6 pages, l'imprime, le remplit avec un stylo (à moitié du temps illisiblement), l'apporte au bureau, et un membre du personnel l'entre manuellement dans leur système DPI. Temps moyen du téléchargement à l'entrée DPI : 3 à 5 jours ouvrables.

Le nouveau processus : Le patient reçoit un message texte ou un lien e-mail 48 heures avant son rendez-vous, remplit le formulaire multi-étapes sur son téléphone en environ 8 minutes, et les données sont disponibles dans le système du cabinet avant qu'il ne franchisse la porte.

Décisions UX du formulaire

Nous avons divisé le formulaire d'accueil en 7 étapes :

  1. Vérification d'identité (nom, DOB, informations de contact)
  2. Informations d'assurance (assureur, ID, numéro de groupe, téléchargement de photo de carte)
  3. Antécédents médicaux (liste de contrôle des conditions, antécédents chirurgicaux)
  4. Médicaments actuels (avec saisie semi-automatique à partir d'une base de données de formulaire ouverte)
  5. Raison de la visite (texte libre + diagramme corporel pour la localisation de la douleur)
  6. Consentement et accords (capture de signature électronique)
  7. Révision et soumission

Quelques détails UX qui ont vraiment fait la différence :

  • Indicateur de progression affichant « Étape 3 sur 7 » a réduit l'abandon d'environ 40 % par rapport à notre prototype initial qui affichait tous les champs à la fois. Nous avons testé cela avec A/B pendant un lancement doux.
  • Téléchargement de photo de carte d'assurance avec rognage automatique et aperçu. Les patients photographient l'avant et l'arrière de leur carte. Cela seul a éliminé environ 60 % de la saisie de données de réception.
  • Saisie semi-automatique de médicaments utilisant l'API RxNorm. Au lieu que les patients tentent d'épeler « hydroxychloroquine », ils tapent « hydro » et sélectionnent dans une liste filtrée. Cela a considérablement réduit les erreurs d'entrée de médicaments.
  • Persistance de la session—si un patient commence le formulaire et est interrompu, sa progression est enregistrée (chiffrée en sessionStorage, jamais localStorage) pendant 30 minutes. Ils peuvent reprendre là où ils ont quitté.
// Saisie semi-automatique de médicaments utilisant l'API RxNorm
const useMedicationSearch = (query: string) => {
  return useQuery({
    queryKey: ['medications', query],
    queryFn: async () => {
      if (query.length < 3) return [];
      const res = await fetch(
        `/api/medications/search?q=${encodeURIComponent(query)}`
      );
      return res.json();
    },
    staleTime: 1000 * 60 * 5, // Cache pendant 5 minutes
    enabled: query.length >= 3,
  });
};

Le point de terminaison de recherche de médicaments côté serveur interroge RxNorm via notre backend AWS, gardant l'appel API externe loin du client et nous permettant de mettre les résultats en cache.

Résultats de performance et scores Lighthouse

Voici l'avant et l'après :

Métrique WordPress (Avant) Next.js + Payload (Après) Amélioration
Lighthouse Mobile 38 94 +147 %
Lighthouse Desktop 61 99 +62 %
First Contentful Paint (Mobile) 4,2s 0,8s -81 %
Largest Contentful Paint (Mobile) 8,1s 1,4s -83 %
Total Blocking Time 1 840 ms 45 ms -98 %
Cumulative Layout Shift 0,34 0,01 -97 %
Time to Interactive 9,3s 1,2s -87 %
Page Weight (Homepage) 4,8 Mo 340 Ko -93 %
Core Web Vitals Pass Non Oui (tous au vert) —

Le score Lighthouse mobile de 94 (pas 100, et je vais expliquer pourquoi dans un instant) a été mesuré sur la page de formulaire d'accueil des patients, qui est la page la plus lourde en JavaScript du site. Les pages de contenu comme la page d'accueil et les pages de services obtiennent systématiquement des scores de 98-100 sur mobile et ordinateur de bureau.

Pourquoi pas un parfait 100 sur mobile ? Deux raisons :

  1. Le widget d'autocomplétion des médicaments nécessite du JavaScript côté client qui ajoute environ 12 Ko compressés à la page du formulaire d'accueil.
  2. Nous utilisons reCAPTCHA v3 sur le formulaire d'accueil comme couche de prévention des bots, et le script reCAPTCHA de Google n'est pas exactement léger. Nous le chargeons paresseusement, mais cela nous coûte toujours quelques points.

Nous avons envisagé de supprimer reCAPTCHA pour atteindre 100, mais l'avantage en matière de sécurité dépasse la métrique de vanité. Un formulaire d'accueil de santé sans protection contre les bots vous demande d'avoir des soumissions de spam mélangées avec des données réelles de patients.

Stratégie de migration : zéro temps d'arrêt, zéro perte de classement

Migrer un site Web de pratique de santé est stressant car les temps d'arrêt signifient littéralement des rendez-vous patients manqués. Voici comment nous l'avons géré :

Migration de contenu

Nous avons écrit un script de migration qui a récupéré le contenu de l'API REST WordPress et l'a transformé en documents Payload CMS. Le script a géré :

  • 47 pages de services
  • 12 profils de médecin/prestataire
  • 89 articles de blog (avec réhébergement d'images)
  • 6 pages de localisation
  • Toutes les métadonnées SEO (titres, descriptions, URL canoniques)

Mappage d'URL

Chaque URL WordPress a été mappée à son équivalent Next.js. Nous avons conservé la même structure d'URL où possible et configuré des redirections 301 dans next.config.js pour la poignée d'URLs qui ont changé :

// next.config.js
const redirects = async () => [
  {
    source: '/services/:slug',
    destination: '/orthopedic-services/:slug',
    permanent: true,
  },
  {
    source: '/team/:slug',
    destination: '/providers/:slug',
    permanent: true,
  },
  // ... 23 autres redirections
];

Basculement DNS

Nous avons utilisé une stratégie de déploiement bleu-vert. Le nouveau site a fonctionné en parallèle pendant deux semaines tandis que nous testions. Le jour du basculement, nous avons mis à jour les enregistrements DNS lors d'une fenêtre de maintenance dimanche soir. Temps d'arrêt visible total : environ 3 minutes (la propagation DNS a été rapide parce que nous avions pré-abaissé les TTL à 60 secondes une semaine avant).

Résultats SEO

Trois mois après le lancement :

  • Le trafic organique a augmenté de 34 %
  • La position moyenne pour « orthopedic doctor near me » s'est améliorée de la position 14 à la position 5
  • Le taux de clics de Google a augmenté de 28 % (les meilleures Core Web Vitals = meilleure expérience des SERP mobile)
  • Zéro erreur 404 dans Search Console pour les URLs précédemment indexées

Plongée profonde dans l'architecture technique

Pour ceux qui veulent le tableau complet :

┌─────────────────────────────────────────────┐
│                  Vercel                       │
│  ┌─────────────────────────────────────────┐ │
│  │  Next.js 15 App Router                  │ │
│  │  - Pages statiques (ISR, revalidation60s)│ │
│  │  - Server Components                    │ │
│  │  - Routes API (proxy uniquement, pas PHI)│ │
│  └─────────────────────────────────────────┘ │
└──────────────────┬──────────────────────────┘
                   │ HTTPS
┌──────────────────▼──────────────────────────┐
│              AWS (BAA HIPAA)                 │
│  ┌──────────────┐  ┌─────────────────────┐  │
│  │  API Gateway  │  │  CloudFront (assets)│  │
│  │  + WAF        │  └─────────────────────┘  │
│  └──────┬───────┘                            │
│         │                                    │
│  ┌──────▼───────┐  ┌─────────────────────┐  │
│  │  ECS Fargate  │──│  RDS PostgreSQL     │  │
│  │  (Payload 3)  │  │  (chiffré)          │  │
│  └──────┬───────┘  └─────────────────────┘  │
│         │                                    │
│  ┌──────▼───────┐  ┌─────────────────────┐  │
│  │  S3 (uploads) │  │  CloudWatch (logs)  │  │
│  │  (chiffré)    │  │  (piste d'audit)    │  │
│  └──────────────┘  └─────────────────────┘  │
└─────────────────────────────────────────────┘

Coût mensuel de l'infrastructure : environ 180-220 $/mois sur AWS (ECS Fargate est étonnamment abordable à cette échelle) plus 20 $/mois pour Vercel Pro. Comparez cela à l'hébergement partagé de 29 $/mois sur lequel ils étaient auparavant—oui, c'est plus cher, mais ils reçoivent une infrastructure admissible HIPAA, une mise à l'échelle automatique, et une sécurité réelle.

Leçons apprises

1. Démarrer les conversations HIPAA tôt. Nous avons passé trois semaines sur la planification de l'architecture avant d'écrire une seule ligne de code. Cela nous a sauvé d'au moins deux redesigns potentiels.

2. Payload CMS v3 en valait la peine. Nous avons commencé ce projet quand Payload 3.0 était en bêta. Il y avait des aspérités—la documentation de migration était incomplète, et certains plugins n'avaient pas été mis à jour. Mais le support natif de Postgres et la nouvelle interface d'administration en faisaient le bon choix.

3. Ne pas sur-concevoir le formulaire d'accueil. Notre premier prototype avait une logique conditionnelle sur six niveaux de profondeur. Le responsable du bureau a regardé et dit : « Ne pouvons-nous pas simplement poser les questions dans l'ordre ? » Il avait raison. Nous avons simplifié, et les taux d'achèvement ont augmenté.

4. Les clients en santé ont besoin d'aide pour la formation CMS. Nous avons fourni trois sessions de formation au lieu de notre habituelle une seule, plus des vidéos Loom enregistrées pour les tâches courantes. L'investissement dans la formation s'est amorti en un mois lorsque le responsable du bureau a pu ajouter une nouvelle page de prestataire sans soumettre un ticket d'assistance.

5. Les budgets de performance ne sont pas négociables. Nous avons défini un budget de performance de <400 Ko de poids de page et <100 ms de Temps Bloquant Total au début du projet. Chaque PR a été vérifiée par rapport à ce budget en CI. La seule fois où nous avons essayé d'ajouter une bibliothèque d'illustration animée, cela a dépassé le budget, et nous l'avons attrapé avant qu'il ne soit livré.

Si vous envisagez une migration similaire pour un site de santé ou d'une industrie réglementée, nous serions heureux de discuter des détails. Vous pouvez nous contacter directement ou consulter notre page de tarification pour les gammes de projets.

FAQ

L'utilisation de Next.js et Payload CMS rend-elle automatiquement un site conforme HIPAA ?

Non. Aucune pile technologique n'est intrinsèquement conforme HIPAA. La conformité HIPAA nécessite des mesures de sauvegarde administratives (politiques, formation, évaluations des risques), des mesures de sauvegarde physiques (contrôles d'accès aux installations), et des mesures de sauvegarde techniques (chiffrement, contrôles d'accès, journaux d'audit). Ce que Next.js et Payload CMS vous donnent, c'est une architecture flexible où vous pouvez correctement mettre en œuvre les mesures de sauvegarde techniques—notamment la nature auto-hébergée de Payload, qui vous permet de contrôler où vivent les PHI.

Pourquoi ne pas utiliser un service de formulaire conforme HIPAA comme Jotform ou FormStack ?

Vous l'absolument pouvez, et pour les cas d'utilisation plus simples, c'est un choix raisonnable. Nous avons évalué le plan HIPAA de Jotform (99 $/mois) et FormStack (83 $/mois). Le problème pour ce client était la profondeur d'intégration—ils voulaient que les données d'accueil circulent dans un workflow personnalisé qui vérifiait l'admissibilité d'assurance en temps réel et préremplissait leur système DPI. Les outils de formulaires prêts à l'emploi ne pouvaient pas gérer cela sans intergiciel significatif, et à ce stade, vous construisez une infrastructure personnalisée de toute façon.

Quel était le coût total du projet et le calendrier ?

Le projet s'élevait à environ 42 000 $ sur 14 semaines. Cela comprenait la découverte et la planification de l'architecture (3 semaines), la conception (2 semaines), le développement (7 semaines), et les tests/migration (2 semaines). L'hébergement continu et la maintenance coûtent environ 250 $/mois incluant les coûts d'infrastructure et une petite retenue d'assistance.

Payload CMS peut-il gérer plusieurs emplacements pour un groupe de soins de santé ?

Oui. Nous avons construit une collection « Emplacements » dans Payload avec des champs pour l'adresse, les heures, les prestataires, l'assurance acceptée, et le contenu spécifique à l'emplacement. Chaque emplacement reçoit sa propre page générée par Next.js avec balisage de données structurées (schéma LocalBusiness) pour le SEO local. Ajouter un nouvel emplacement est aussi simple que de créer une nouvelle entrée dans le panneau d'administration de Payload.

Comment gères-tu les exigences de rétention et de suppression des données des patients ?

Nous avons implémenté des politiques de cycle de vie des données automatisées. Les soumissions de formulaires d'accueil sont conservées pendant 7 ans (correspondant à la exigence de rétention des dossiers médicaux de l'État du cabinet), après quoi elles sont automatiquement archivées sur S3 Glacier et finalement supprimées. Les patients peuvent également demander l'accès aux données ou la suppression en vertu des lois sur la confidentialité des États—nous avons construit un workflow d'administration dans Payload où le personnel peut traiter ces demandes avec une piste d'audit complète.

Que se passe-t-il si le serveur Payload CMS est en panne ?

Le frontend Next.js sert des pages générées statiquement à partir du CDN de Vercel, donc le site Web principal reste disponible même si le backend Payload est complètement hors ligne. Le formulaire d'accueil des patients serait indisponible lors d'une panne du backend, mais nous avons configuré ECS avec des politiques de redémarrage automatique, des vérifications de santé toutes les 30 secondes, et des alarmes CloudWatch qui alertent à la fois notre équipe et le contact informatique du cabinet. En 6 mois de production, nous avons eu zéro temps d'arrêt non planifié.

Cette architecture est-elle excessive pour un petit cabinet avec une seule localisation ?

Cela dépend de ce que vous faites avec les données des patients. Si vous avez simplement besoin d'un site de brochure avec un numéro de téléphone et une adresse, WordPress avec un bon thème convient bien—vous n'avez besoin de rien de tout cela. Mais à partir du moment où vous collectez des PHI sur votre site Web (formulaires d'accueil, questionnaires médicaux, demandes de rendez-vous avec détails médicaux), vous avez besoin d'une infrastructure qui supporte les contrôles de sécurité appropriés. L'architecture que nous avons construite se réduit bien—un cabinet à une seule localisation coûterait moins cher en infrastructure en raison du trafic inférieur.

Comment la migration a-t-elle affecté les classements Google ?

Nous avons observé une brève fluctuation de classement (environ 10 jours) immédiatement après la migration, ce qui est normal. En semaine trois, les classements s'étaient stabilisés et suivaient une tendance à la hausse. En mois trois, le trafic organique avait augmenté de 34 % et les mots-clés principaux du cabinet avaient amélioré une moyenne de 4 positions. L'amélioration des Core Web Vitals a été le facteur le plus important—Google avait pénalisé leur ancien site pour sa mauvaise performance mobile dans les résultats de recherche.