Test de régression visuelle : méthode de test automatisé qui compare des captures d'écran d'une interface utilisateur entre deux versions pour détecter les changements visuels non intentionnels — défini par l'ISTQB comme une technique de test de régression appliquée à la couche d'affichage d'un système logiciel.
Voici une question que personne ne pose dans les réunions de conformité : quand votre outil de test visuel prend une capture d'écran de votre portail patient, où va cette image ?
La capture montre un tableau de bord avec le nom du patient, sa date de naissance, ses résultats d'analyses, ses prescriptions en cours, peut-être un historique de rendez-vous. C'est un environnement de staging, certes. Mais les données sont réalistes — parce que tester avec des données absurdes ne teste rien du tout. Et cette capture vient d'être envoyée vers un serveur cloud aux États-Unis pour être comparée pixel par pixel avec une image de référence.
Félicitations : vous venez de créer un incident de conformité potentiel.
Cet article s'adresse aux responsables qualité, aux DSI et aux DPO des éditeurs de logiciels de santé, des hôpitaux, des cliniques et des startups healthtech qui veulent tester leurs interfaces sans compromettre les données de leurs patients.
Les interfaces santé ne sont pas des interfaces ordinaires
Une interface de santé a une particularité que peu d'autres domaines partagent : les informations qu'elle affiche peuvent avoir des conséquences directes sur la vie des patients.
Un dosage de médicament affiché avec une décimale mal placée. Un résultat d'analyse avec une unité tronquée. Un indicateur de gravité dont la couleur a changé après une mise à jour CSS — le rouge "critique" est devenu orange "attention modérée". Un calendrier de rendez-vous où la date s'affiche dans le mauvais format et le patient se présente le mauvais jour pour une procédure préopératoire.
Ces scénarios ne relèvent pas de l'hypothèse. L'ANSM (Agence Nationale de Sécurité du Médicament) et la FDA recensent régulièrement des incidents liés à des erreurs d'affichage dans les logiciels de santé. Le rapport 2023 de la FDA sur les rappels de dispositifs médicaux logiciels identifie les erreurs d'interface utilisateur comme la troisième cause de rappels, derrière les erreurs de calcul et les problèmes de transmission de données.
La différence avec les autres secteurs est simple : dans le e-commerce, un bug visuel coûte de l'argent. Dans la santé, un bug visuel peut coûter une vie. Cette réalité change fondamentalement la manière dont vous devez penser le test de vos interfaces.
Les professionnels de santé qui utilisent vos logiciels — médecins, infirmières, pharmaciens, biologistes — travaillent sous pression, souvent en situation de fatigue, avec des dizaines de patients à gérer. Ils n'ont pas le temps de vérifier si l'interface affiche correctement les informations. Ils font confiance à ce qu'ils voient. Et cette confiance doit être justifiée par des processus de test rigoureux.
HIPAA, HDS, RGPD : le triptyque réglementaire et ses implications pour le test visuel
Le secteur de la santé est probablement le domaine le plus réglementé en matière de protection des données. Et ces réglementations ont des implications directes sur la manière dont vous pouvez — et ne pouvez pas — tester vos interfaces.
HIPAA (Health Insurance Portability and Accountability Act). Aux États-Unis, HIPAA protège les PHI (Protected Health Information) — toute information qui permet d'identifier un patient et qui est liée à son état de santé, aux soins reçus ou au paiement de ces soins. La Security Rule d'HIPAA exige des garanties techniques pour protéger les PHI électroniques, notamment le contrôle d'accès, l'audit trail, l'intégrité des données et la sécurité de la transmission. Une capture d'écran d'une interface patient contenant des PHI est elle-même un PHI. L'envoyer vers un outil de test SaaS signifie que ce fournisseur devient un Business Associate au sens d'HIPAA, ce qui nécessite un BAA (Business Associate Agreement) — et même avec un BAA, la responsabilité en cas de breach reste partagée. Les amendes HIPAA vont de 100 à 50 000 dollars par violation, avec un plafond de 1,5 million de dollars par catégorie et par an. En 2024, l'OCR (Office for Civil Rights) a prononcé plus de 130 millions de dollars d'amendes cumulées.
HDS (Hébergement de Données de Santé). En France, la certification HDS est obligatoire pour tout hébergeur de données de santé à caractère personnel. Introduite par le décret du 26 février 2018 et renforcée par la mise à jour de 2024, cette certification exige que l'hébergement soit réalisé sur le territoire de l'Union européenne, avec des garanties techniques et organisationnelles spécifiques. Si votre outil de test visuel envoie des captures d'écran contenant des données de santé vers un cloud non certifié HDS, vous êtes en infraction. Et la certification HDS n'est pas qu'une formalité : elle implique un audit par un organisme accrédité par le COFRAC, un système de management de la sécurité de l'information conforme à ISO 27001, et des contrôles spécifiques sur la localisation et l'accès aux données.
RGPD et données de santé. Le RGPD classe les données de santé comme des données sensibles (article 9), soumises à un régime de protection renforcé. Leur traitement est interdit par principe, avec des exceptions limitées — dont le consentement explicite et l'intérêt vital. Une capture d'écran d'une interface patient contenant des données de santé, envoyée vers un outil de test SaaS, constitue un traitement de données sensibles. Ce traitement doit être justifié par une base légale, documenté dans votre registre des traitements, et soumis à une analyse d'impact (AIPD) si le transfert est hors UE. La CNIL a été claire : le transfert de données de santé vers les États-Unis, même sous le Data Privacy Framework, doit faire l'objet d'une vigilance renforcée.
Ce que ces trois réglementations disent ensemble, c'est que les données de santé qui apparaissent dans vos captures d'écran ne sont pas de simples images. Ce sont des données sensibles protégées par des régimes juridiques stricts. Et chaque fois que ces images quittent votre infrastructure, vous créez un point de risque réglementaire.
Pourquoi les données de staging sont un faux sentiment de sécurité
"Nous ne testons pas avec des données réelles." C'est l'argument que vous entendez dans presque toutes les équipes de développement du secteur santé. Et c'est un argument qui résiste mal à l'examen.
D'abord, il y a la question de ce que "données réelles" signifie. Beaucoup d'environnements de staging dans la santé utilisent des copies anonymisées ou pseudonymisées de données de production. L'anonymisation parfaite est notoirement difficile à réaliser dans le domaine médical — des études ont montré que 87 % de la population américaine peut être identifiée de manière unique avec seulement trois informations : le code postal, la date de naissance et le sexe. Un dossier patient pseudonymisé qui conserve la date de naissance, le code postal et le diagnostic principal n'est pas anonyme — il est réidentifiable.
Ensuite, il y a les données synthétiques. Oui, vous pouvez générer des patients fictifs avec des noms aléatoires, des dates de naissance inventées et des pathologies assignées par algorithme. Mais pour que vos tests soient pertinents, ces données doivent être réalistes. Un résultat d'HbA1c de 6,4 % pour un patient diabétique de type 2 sous metformine. Un INR de 2,3 pour un patient sous warfarine. Ces valeurs sont médicalement cohérentes — et c'est exactement ce qui les rend potentiellement qualifiables de données de santé par un régulateur prudent, si elles sont associées à un profil patient suffisamment détaillé.
Enfin, il y a la réalité du terrain. Les développeurs copient parfois des données de production vers le staging pour reproduire un bug. Un médecin signale un problème d'affichage sur le dossier d'un patient spécifique, l'équipe de développement a besoin de reproduire le contexte exact. Ces copies "temporaires" ont une fâcheuse tendance à devenir permanentes. Et quand votre outil de test visuel prend une capture d'écran de cet environnement, il capture potentiellement de vraies données patients.
La seule manière de neutraliser ce risque structurellement est que les captures d'écran ne quittent jamais votre périmètre. Peu importe ce qu'elles contiennent — données réelles, pseudonymisées, synthétiques ou mélangées — si elles restent sur votre machine, le risque de transfert non autorisé est éliminé par conception.
Le test visuel comme gardien de l'accessibilité
Il y a un aspect du test visuel dans la santé dont on parle trop peu : l'accessibilité.
Les utilisateurs des interfaces de santé ne sont pas seulement les professionnels de santé. Ce sont aussi les patients eux-mêmes — via les portails patients, les applications de suivi, les carnets de santé numériques. Et ces patients incluent des personnes âgées avec une vision dégradée, des personnes daltoniennes qui ne distinguent pas certaines couleurs, des personnes avec des handicaps moteurs qui naviguent au clavier ou avec des technologies d'assistance.
En France, le RGAA (Référentiel Général d'Amélioration de l'Accessibilité) impose aux services publics numériques d'être accessibles. Les établissements de santé publics sont directement concernés. Le secteur privé n'y échappe pas non plus : la directive européenne sur l'accessibilité du web (2016/2102) et l'European Accessibility Act (2025) étendent progressivement ces obligations.
Le test visuel détecte les régressions d'accessibilité qui se manifestent visuellement. Un contraste de texte qui passe en dessous du ratio 4.5:1 requis par WCAG 2.1 niveau AA. Une zone cliquable qui rétrécit en dessous de 44x44 pixels. Un focus visible qui disparaît après une refonte CSS. Un texte qui ne s'agrandit pas correctement quand l'utilisateur augmente la taille de police dans son navigateur.
Pour les patients âgés — qui représentent une part croissante des utilisateurs de portails patients avec le vieillissement de la population et la numérisation du parcours de soins — ces régressions ne sont pas de simples désagréments. Une police trop petite sur un résultat d'analyse signifie un patient qui ne comprend pas ses résultats. Un bouton mal contrasté sur une page de prise de rendez-vous signifie un rendez-vous manqué. Un formulaire de renouvellement d'ordonnance dont les champs se chevauchent sur mobile signifie un patient qui ne peut pas accéder à ses médicaments.
Le test visuel ne remplace pas un audit d'accessibilité complet. Mais il empêche les régressions — et dans un contexte où l'audit initial a été fait et où le défi est de maintenir le niveau de conformité au fil des sprints et des mises à jour, le test de régression visuelle est le filet de sécurité le plus efficace.
Le on-premise comme seule réponse structurelle
Récapitulons les contraintes. HIPAA exige la protection des PHI et des BAA avec chaque prestataire. HDS impose un hébergement certifié sur le territoire européen. Le RGPD classe les données de santé comme sensibles et restreint leur transfert. Les données de staging ne sont pas nécessairement plus sûres que les données de production. Et l'accessibilité impose des exigences visuelles continues.
Face à ces contraintes, il y a deux approches. La première est de se conformer à chaque exigence individuellement : signer un BAA avec votre fournisseur SaaS, vérifier sa certification HDS, documenter le transfert dans votre registre RGPD, réaliser une AIPD, mettre en place des contrôles d'anonymisation sur votre staging. C'est faisable, mais c'est un édifice complexe où chaque maillon doit tenir — et un seul maillon faible suffit à créer une brèche.
La deuxième approche est de supprimer le problème à la racine : si les captures d'écran ne quittent jamais votre infrastructure, la plupart de ces exigences deviennent caduques. Pas de transfert à documenter, pas de BAA à signer, pas de certification à vérifier chez un tiers, pas d'AIPD à réaliser pour le test visuel. Vous gardez le contrôle total, et votre posture de conformité se simplifie radicalement.
C'est l'approche on-premise. Et dans le secteur de la santé, ce n'est pas un choix conservateur ou technophobe. C'est la réponse la plus rationnelle à un environnement réglementaire qui ne pardonne pas les approximations.
Delta-QA et les spécificités du secteur santé
Delta-QA est un outil de test visuel no-code qui fonctionne entièrement en local. Voici ce que cela signifie concrètement pour le secteur santé.
Zéro transfert de données. Les captures d'écran de vos interfaces patients restent sur la machine de votre testeur. Pas de cloud, pas d'API externe, pas de serveur tiers. Que votre portail patient affiche des données réelles, pseudonymisées ou synthétiques, elles ne quittent jamais votre périmètre. Pour un DPO, c'est un dossier de conformité considérablement simplifié.
Pas de compétence développeur requise. Dans le secteur santé, les équipes QA sont souvent composées de profils fonctionnels — des personnes qui connaissent les parcours de soins, les processus métier, les exigences réglementaires, mais qui ne codent pas. Delta-QA fonctionne par navigation : vous ouvrez votre application, vous parcourez les écrans comme le ferait un utilisateur, et l'outil enregistre et compare. C'est une compétence que n'importe quel testeur fonctionnel maîtrise déjà.
Détection déterministe et auditable. L'algorithme structurel de Delta-QA analyse le CSS réel plutôt que de comparer des pixels. Quand il détecte un changement, il produit un rapport explicite : "la taille de police est passée de 16px à 14px sur l'élément .patient-name", "le contraste du bouton .confirm a changé de 4.8:1 à 3.2:1". Dans un contexte où chaque décision de test doit être justifiable — lors d'un audit HDS, d'une inspection ANSM ou d'une investigation HIPAA — cette traçabilité est un avantage important par rapport aux approches IA dont les résultats sont une probabilité, pas une certitude.
Détection des régressions d'accessibilité. Parce que Delta-QA analyse la structure CSS, il détecte les changements qui affectent l'accessibilité visuelle : modifications de contraste, réductions de taille de police, changements de dimensions des zones interactives. Ce n'est pas un outil d'audit d'accessibilité, mais c'est un outil qui empêche les régressions d'accessibilité de passer inaperçues entre deux audits.
Gratuit pour commencer. La version Desktop de Delta-QA est gratuite, sans limite de captures et sans durée d'essai. Pour un hôpital ou une clinique qui veut évaluer le test visuel sur son DPI (Dossier Patient Informatisé) ou son portail patient, il n'y a pas de processus d'achat à lancer. Vous pouvez tester l'outil dans les conditions réelles de votre environnement avant toute décision budgétaire.
Les limites à connaître
Le test visuel, même on-premise, n'est pas une solution universelle dans le secteur santé.
Il ne teste pas la logique métier. Le test visuel vérifie que l'affichage est correct, pas que les données affichées sont correctes. Si votre algorithme de calcul de dosage renvoie une valeur erronée, le test visuel ne la détectera que si cette erreur modifie l'apparence de l'interface par rapport à la référence. Un calcul incorrect qui produit un résultat visuellement plausible passera inaperçu. Les tests fonctionnels et les tests unitaires restent indispensables.
Delta-QA ne s'intègre pas dans un pipeline CI/CD cloud. Si votre organisation a investi dans un pipeline d'intégration continue hébergé dans le cloud et que vous souhaitez que chaque merge request déclenche automatiquement un test visuel, Delta-QA n'est pas conçu pour ce workflow. C'est un outil desktop, fait pour les tests manuels assistés et les campagnes de test structurées. Pour les organisations de santé, cette approche est souvent plus réaliste que l'automatisation complète, mais c'est une limite à évaluer en fonction de votre maturité DevOps.
Il ne couvre pas tous les aspects de l'accessibilité. Le test visuel détecte les régressions visuelles d'accessibilité, pas les problèmes structurels. Un lecteur d'écran qui ne peut pas naviguer dans votre formulaire parce que les rôles ARIA sont mal configurés ne sera pas détecté par un test visuel. Un audit d'accessibilité complet avec des outils spécialisés (axe, WAVE, Lighthouse) reste nécessaire.
La couverture dépend de vos scénarios. Le test visuel ne teste que les écrans que vous avez définis comme scénarios de test. Si un parcours patient critique n'est pas inclus dans vos scénarios, les régressions visuelles sur ce parcours ne seront pas détectées. La qualité de votre couverture de test visuel dépend de la qualité de votre sélection de scénarios.
FAQ
Les captures d'écran d'un portail patient sont-elles des PHI au sens d'HIPAA ?
Oui, si elles contiennent l'un des 18 identifiants définis par HIPAA : nom, date de naissance, adresse, numéro de sécurité sociale, numéro de dossier médical, ou toute autre information permettant d'identifier le patient. Une capture d'écran d'un tableau de bord patient qui affiche le nom et des résultats d'analyses est un PHI électronique, soumis aux mêmes exigences de protection que le dossier patient lui-même.
Un outil de test visuel SaaS doit-il être certifié HDS en France ?
Si l'outil reçoit et stocke des captures d'écran contenant des données de santé à caractère personnel, même temporairement, il agit comme hébergeur de ces données. La certification HDS est alors requise. En pratique, très peu d'outils de test visuel SaaS sont certifiés HDS — ce n'est pas leur cœur de métier. C'est pourquoi l'approche on-premise, qui élimine le besoin de certification chez un tiers, est structurellement plus simple pour la conformité.
Comment le test visuel aide-t-il l'accessibilité des interfaces santé ?
Le test visuel détecte les régressions d'accessibilité visuelles : baisse de contraste de texte en dessous des ratios WCAG 2.1 (4.5:1 pour le texte normal, 3:1 pour le texte agrandi), réduction de la taille des zones cliquables, disparition du focus visible, changements de taille de police. Pour les patients âgés ou en situation de handicap visuel, ces régressions peuvent rendre une interface inutilisable. Le test visuel ne remplace pas un audit RGAA/WCAG complet, mais il empêche la dégradation entre deux audits.
Combien de temps faut-il pour mettre en place le test visuel sur un DPI ?
Avec Delta-QA, la mise en place initiale prend entre une et trois journées selon la complexité de votre DPI. La première journée consiste à identifier les parcours critiques (consultation de dossier patient, prescription, résultats d'analyses, prise de rendez-vous). La deuxième journée consiste à créer les scénarios de test et les captures de référence. La troisième, si nécessaire, permet d'affiner les seuils de sensibilité et de former l'équipe QA. Aucune compétence en développement n'est requise.
Le test visuel peut-il détecter les erreurs d'affichage de dosage médicamenteux ?
Le test visuel détecte les changements d'affichage par rapport à une référence. Si un dosage s'affichait correctement dans la version de référence (par exemple "500 mg") et qu'une mise à jour CSS a modifié l'affichage (par exemple en tronquant à "500" sans l'unité, ou en changeant le formatage à "5.00 mg"), le test visuel détectera ce changement. En revanche, si le dosage affiché est incorrect depuis la version de référence (erreur dans le backend), le test visuel ne le détectera pas — c'est le rôle des tests fonctionnels.
Quelle différence entre anonymisation et pseudonymisation pour les données de staging santé ?
L'anonymisation rend impossible l'identification d'une personne, même avec des informations complémentaires. C'est un processus irréversible. La pseudonymisation remplace les identifiants directs (nom, numéro de sécurité sociale) par des pseudonymes, mais l'identification reste possible avec la table de correspondance. Le RGPD ne s'applique pas aux données véritablement anonymisées, mais s'applique aux données pseudonymisées. En pratique, l'anonymisation parfaite de données médicales est extrêmement difficile à garantir, ce qui renforce l'argument en faveur du on-premise : si vous n'êtes pas certain que vos données de staging sont parfaitement anonymisées, ne les envoyez pas à l'extérieur.
Conclusion
Le test visuel dans le secteur de la santé n'est pas une question de perfectionnisme esthétique. C'est une question de sécurité patient, de conformité réglementaire et de confiance.
Les interfaces santé affichent les données les plus sensibles qui existent : les données de santé des patients. Chaque capture d'écran de ces interfaces est un document potentiellement soumis à HIPAA, à la certification HDS, au RGPD. Chaque transfert de ces captures vers un cloud tiers est un risque réglementaire mesurable.
L'approche on-premise n'est pas un compromis. C'est la seule approche qui élimine structurellement le risque de transfert non autorisé de données de santé. Et avec des outils comme Delta-QA, cette approche n'exige ni budget conséquent, ni compétences en développement, ni infrastructure dédiée.
Vos patients vous font confiance avec leurs données les plus intimes. Vos captures d'écran de test devraient mériter le même niveau de protection.
Essayer Delta-QA Gratuitement →