Retour aux études de cas
Pharma & Soins aux patientsDéveloppement d'applications SaaSSécurité & Conformité
Portail numérique patient & PS réglementé
Construction d'une plateforme numérique haute accessibilité reliant patients, aidants familiaux et professionnels de santé habilités, dans un cadre réglementaire aligné FDA et HIPAA, sans ralentir le rythme de publication des contenus.
Plateforme conforme FDA reliant patients, soignants et professionnels de santé
Client
Confidentiel — Pharmaceutique / maladie rare
Secteur
Pharma & Soins aux patients
Calendrier
7 mois
Technologies
8+ outils
Le défi
!La plateforme devait servir trois audiences distinctes — patients, aidants familiaux et professionnels de santé (PS) habilités — depuis une seule base de code, avec des contenus strictement cloisonnés par rôle. Toute fuite d'informations de dosage réservées aux prescripteurs vers l'expérience patient aurait créé une exposition réglementaire, donc le modèle d'accès devait être appliqué au niveau de l'API, pas seulement masqué dans l'interface.
!La conformité WCAG 2.1 AA était une exigence ferme, pas une option, car la population de patients atteints d'une maladie rare inclut de nombreux utilisateurs à mobilité réduite, malvoyants ou souffrant de fatigue cognitive liée au traitement. Les prototypes internes existants avaient été conçus sans considération d'accessibilité et auraient nécessité une reconstruction quasi totale de la bibliothèque de composants.
!Chaque contenu médical destiné aux patients devait passer par un workflow d'approbation réglementaire multi-étapes impliquant des réviseurs médicaux, juridiques et réglementaires (MLR) avant publication. Le processus antérieur du client reposait sur des échanges par email et des tableurs partagés, prenant régulièrement deux à trois semaines par mise à jour, sans piste d'audit fiable sur qui avait approuvé quelle version.
!Les données médicales et personnelles sensibles devaient être gérées selon des contrôles alignés HIPAA — chiffrement, restrictions d'accès au niveau des champs, journalisation d'audit détaillée — même si la plateforme elle-même n'était pas techniquement une entité couverte. L'équipe conformité du client exigeait des preuves documentées de ces contrôles pour ses propres audits, pas seulement une assurance verbale de bonnes pratiques.
!Les aidants familiaux avaient besoin d'une véritable communauté de pair-aidance, mais des forums non modérés dans le contexte d'une maladie rare comportent de vrais risques : partage de conseils thérapeutiques non vérifiés, révélations de détresse émotionnelle, ou divulgation involontaire de données de santé protégées dans des publications publiques. Le client avait besoin d'un signalement automatisé couplé à une filière d'escalade humaine formée, pas d'un simple bouton de signalement sans suite.
!L'organisation opérait dans plusieurs pays avec des autorités réglementaires différentes (la FDA aux États-Unis, plus des exigences émergentes sur d'autres marchés), ce qui signifiait que la localisation des contenus et les jalons d'approbation spécifiques à chaque région devaient être intégrés au même pipeline plutôt qu'ajoutés après coup sous forme de systèmes séparés.
!L'IT interne du client ne disposait d'aucune pratique DevOps établie pour ce type de produit SaaS réglementé, donc la plateforme devait fournir aux auditeurs, sur demande, des preuves de disponibilité, de reprise après sinistre et de contrôle des changements, sans obliger le client à recruter une équipe dédiée d'ingénierie plateforme.
!Le délai de sept mois était fixe pour coïncider avec une annonce publique de traitement déjà planifiée, ne laissant aucune marge pour que l'audit d'accessibilité, la revue de sécurité ou la validation MLR prennent du retard sans compromettre la date de lancement.
Notre solution
Nous avons conçu dès le premier jour une architecture double audience à contenu filtré par rôle, appliquant les frontières patient / aidant / PS au niveau de l'API et des requêtes base de données via des tokens scopés et des permissions au niveau ligne, plutôt que de s'appuyer uniquement sur le routage frontend pour masquer le contenu restreint.
L'ensemble de la bibliothèque de composants a été construit en conformité WCAG 2.1 AA dès le premier sprint, avec compatibilité complète lecteurs d'écran, navigation clavier intégrale, modes d'affichage à haut contraste et taille de texte ajustable, validés en continu par des vérifications d'accessibilité automatisées dans le pipeline CI plutôt que lors d'une vérification finale avant lancement.
Nous avons remplacé le processus de revue MLR par email par un pipeline de contenu digital structuré avec jalons d'approbation par étapes, attribution de réviseurs, commentaires en ligne et historique de versions immuable, garantissant que chaque page publiée porte une trace vérifiable de qui a approuvé quelle version et quand.
La gestion des données alignée HIPAA a été mise en œuvre au niveau infrastructure : chiffrement au repos et en transit, contrôles d'accès au niveau des champs liés au rôle utilisateur, et journalisation d'audit complète de chaque lecture et écriture sur les dossiers sensibles, fournissant à l'équipe conformité des preuves exportables pour ses propres audits.
Un module communauté d'aidants modéré a été développé avec signalement automatisé par mots-clés et analyse de sentiment, une file de modération humaine avec SLA définis, et l'application stricte de règles de messages sûrs empêchant que des allégations médicales non vérifiées restent visibles sans revue.
Nous avons conçu le pipeline de contenu avec des jalons d'approbation adaptés à chaque région dès la conception, afin que les variantes de contenu localisées soient acheminées vers les bons réviseurs réglementaires pour chaque marché, sans nécessiter de plateformes séparées ni de bases de code dupliquées.
La plateforme a été déployée sur une infrastructure AWS multi-région active-passive gérée via Terraform, offrant au client un basculement automatisé, des procédures de reprise après sinistre documentées, et un historique de changements en infrastructure-as-code répondant aux exigences d'audit sans équipe plateforme interne.
Nous avons piloté un plan de livraison en phases contre l'échéance fixe de sept mois, en plaçant l'audit d'accessibilité et la revue de sécurité dès les mois quatre et cinq, afin que tout travail de correction dispose d'une marge complète avant la validation MLR et la date de lancement.
Impact mesurable
Standard accessibilité
WCAG 2.1 AA
Conformité intégrale vérifiée par un audit tiers indépendant avant le lancement public.
Cycle d'approbation contenu
60% plus rapide
Les workflows de revue digitaux par étapes ont remplacé les chaînes MLR manuelles par email, réduisant des délais de plusieurs semaines à quelques jours.
SLA disponibilité
99,9%
Le déploiement actif-passif multi-région avec failover automatisé a répondu à l'exigence de disponibilité de niveau clinique du client.
Conformité données
Aligné HIPAA
Toutes les données patients et aidants chiffrées au repos et en transit, contrôlées par rôle, et entièrement auditables.
Délai de livraison
7 mois, dans les temps
Le lancement a été livré à la date liée à l'annonce publique de traitement du client, sans retard sur la validation réglementaire.
Segmentation d'audience
3 niveaux filtrés par rôle
Les expériences patient, aidant et PS entièrement séparées au niveau de l'API, sans aucune fuite de contenu signalée après lancement.
“Réussir l'accessibilité dans un environnement réglementé est vraiment difficile, et réussir en parallèle les preuves de conformité l'est encore plus. SystimaNX a livré une plateforme que les patients peuvent réellement utiliser, en laquelle nos réviseurs MLR ont confiance, et que notre équipe juridique a validée sans aucun point ouvert. Cette combinaison est rare.”
Stack technologique
Next.jsReactNode.jsPostgreSQLAWSTerraformWCAG toolingOkta