Sujet 3.7 — Tests et assurance qualité

En une phrase : Dans la santé et l'action sociale, les tests et l'assurance qualité ne sont pas une phase que vous faites avant la mise en production mais une discipline continue qui fournit une grande partie de la preuve qu'un service est cliniquement sûr, accessible, sécurisé, et apte à toucher les soins d'un patient.

Pourquoi c'est important dans la santé et l'action sociale#

Chaque service numérique porte des défauts ; les seules questions sont combien, à quel point graves, et si vous les trouvez avant ou après qu'un patient soit affecté. Dans une application grand public, un bogue non détecté gaspille l'après-midi d'un utilisateur. Dans un système clinique, il peut afficher les allergies du mauvais patient, arrondir incorrectement une dose de médicament pédiatrique, ou laisser tomber silencieusement une orientation dans une file d'attente que personne ne surveille. Les tests sont l'effort organisé pour trouver ces défauts tôt, et l'assurance qualité est le système plus large de contrôles qui empêche la qualité de dépendre de la chance ou de l'héroïsme.

C'est pourquoi les tests dans l'IT de santé sont indissociables de la sécurité clinique. Les dangers consignés dans un registre des dangers DCB0129/0160 (voir Sujet 1.6 — Sécurité clinique et gestion des risques) ne sont véritablement atténués que lorsqu'un test prouve que l'atténuation fonctionne et continue de fonctionner après chaque changement subséquent. Un dossier de sécurité qui affirme « le système empêche les ordonnances en double » sans un test reproductible derrière est une affirmation, pas une assurance. Les tests sont la base de preuve sous l'argument de sécurité clinique.

Les enjeux concernent aussi l'équité et la confiance publique. Un service qui n'a jamais été testé contre les normes d'accessibilité exclura les utilisateurs handicapés par défaut (voir Sujet 1.9 — Inclusion numérique et accessibilité). Un service testé seulement avec des copies de dossiers de patients en direct risque une violation de données qui érode la confiance dont dépend le NHS. Et l'argent n'est pas négligeable : retravailler un défaut trouvé en exploitation en direct coûte plusieurs fois plus que de l'attraper en conception, et un incident clinique grave coûte bien plus que les deux. Des tests inadéquats ne sont pas une économie ; c'est une facture différée et gonflée, parfois payée en préjudice.

Concepts fondamentaux#

Tests versus assurance qualité. Les tests sont l'acte d'exercer un système pour trouver des défauts et confirmer le comportement. L'assurance qualité est l'ensemble plus large de processus — normes, révisions, définitions de terminé, portes — qui intègrent la qualité plutôt que de l'inspecter à la fin. Les tests vous disent si cette construction fonctionne ; l'AQ est pourquoi vos constructions ont tendance à fonctionner du tout. Les deux comptent, et les dirigeants financent souvent le premier en négligeant le second.

La pyramide de tests et le décalage vers la gauche (shift-left). Une stratégie de test saine a de nombreux tests unitaires rapides et bon marché (vérifiant des fonctions individuelles), moins de tests d'intégration (vérifiant que les composants fonctionnent ensemble), et un petit nombre de tests de bout en bout lents et coûteux (vérifiant des parcours utilisateur entiers). Cette « pyramide de tests » garde la rétroaction rapide et la maintenance abordable. Elle s'associe au test shift-left — déplacer les tests plus tôt dans le cycle de vie, afin que les défauts soient conçus en dehors à moindre coût plutôt que trouvés dans une précipitation frénétique avant la mise en production. Une pyramide inversée (majoritairement des tests de bout en bout manuels) est lente, fragile, et un signal d'alerte.

Tests fonctionnels et non fonctionnels. Le test fonctionnel demande « le système fait-il ce qu'il devrait ? » — calculs corrects, flux de travail corrects, données correctes. Le test non fonctionnel demande « à quel point se comporte-t-il bien ? » — performance et charge (reste-t-il réactif quand tout le trust se connecte à 8h ?), sécurité (peut-il être compromis ?), fiabilité, et accessibilité. Dans la santé et l'action sociale, les échecs non fonctionnels sont souvent les plus dangereux : un système fonctionnellement parfait mais qui expire pendant un appel de réanimation a échoué cliniquement.

Test de régression. Le test de régression réexécute les tests existants après un changement pour confirmer que corriger ou ajouter une chose n'en a pas cassé une autre. Dans les systèmes cliniques en direct, c'est l'habitude de sécurité la plus importante : la plupart des incidents logiciels cliniques ne proviennent pas de nouvelles fonctionnalités mais de changements qui ont discrètement cassé un comportement fonctionnel. Une suite de régression fiable est ce qui vous permet de changer un système en direct sans retenir votre souffle.

Automatisation des tests et intégration continue. L'automatisation des tests utilise un logiciel pour exécuter les tests de manière reproductible, afin qu'une grande suite s'exécute en quelques minutes à chaque changement. Combinée avec l'intégration continue — fusionner et tester automatiquement les changements fréquemment — cela transforme les tests d'un événement occasionnel en un filet de sécurité constant (voir Sujet 3.5 — Cycles de vie de livraison). L'automatisation ne remplace pas le jugement humain ; elle libère les humains pour faire les tests exploratoires et cliniques que les machines ne peuvent pas.

Test d'acceptation. Le test d'acceptation, et spécifiquement le test d'acceptation utilisateur (UAT), est là où de vrais cliniciens et utilisateurs confirment que le système fonctionne dans leur véritable contexte avant sa mise en production. Le test d'acceptation opérationnel (OAT) confirme que le service peut être exploité, sauvegardé, et récupéré. L'UAT avec de véritables utilisateurs finaux attrape les incompatibilités de flux de travail qu'aucun test de développeur ne trouvera.

Environnements de test et données de test sûres. Un environnement de déploiement est un système où le logiciel s'exécute — typiquement les niveaux développement, test, mise en scène, et production. Les tests ont besoin d'environnements qui ressemblent à la production mais ne doivent jamais utiliser négligemment des données de patients en direct. La pratique sûre utilise des données synthétiques (générées artificiellement) ou des données correctement anonymisées, afin que tester un formulaire d'orientation ne puisse pas divulguer le diagnostic d'un véritable citoyen.

Portes de qualité, définition de terminé, et gestion des défauts. Une définition de terminé énonce ce que signifie « terminé » (testé, accessible, documenté, révisé pour la sécurité) afin que la qualité ne soit pas négociable par fonctionnalité. Les portes de qualité sont des points de contrôle qu'un changement doit franchir pour progresser. Le triage des défauts est le processus discipliné consistant à évaluer les défauts trouvés pour la gravité et l'impact clinique, et à décider quoi corriger, quand, et ce qui peut être livré comme problème connu.

Bonnes pratiques#

1. Construisez la pyramide et décalez les tests vers la gauche. Investissez dans une large base de tests unitaires et d'intégration automatisés rapides, exécutés à chaque changement, afin que les défauts émergent en quelques minutes après avoir été écrits plutôt que des semaines plus tard en UAT. Réservez les tests de bout en bout lents pour la poignée de parcours critiques — l'ordonnance, l'orientation, la correspondance d'identité. Cela rend les tests moins chers et plus rapides, ce qui est ce qui fait réellement que les équipes en font plus.

2. Traitez le test de régression comme un contrôle de sécurité clinique. Avant qu'aucun changement n'atteigne un système clinique en direct, une suite de régression automatisée doit confirmer que le comportement existant et pertinent pour la sécurité fonctionne toujours. Mappez vos dangers les plus élevés du registre des dangers DCB0129/0160 directement à des tests de régression nommés, afin qu'un changement qui réintroduirait un danger connu fasse échouer la construction automatiquement. C'est le mécanisme qui vous permet d'itérer sur des systèmes en direct sans accumuler de risque clinique silencieux.

3. Ne testez jamais avec des données de patients en direct par défaut. Provisionnez les environnements de test et de mise en scène avec des données synthétiques ou robustement anonymisées, gouvernées par la même discipline de gouvernance de l'information et de DPIA que la production (voir Sujet 1.7 — Gouvernance de l'information, protection des données et cybersécurité). Si un test spécifique nécessite véritablement des données de type production, traitez-le comme une exception contrôlée avec une base légale documentée, une minimisation, et un audit — pas comme une commodité routinière. Une base de données de test est toujours une base de données de patients.

4. Testez les exigences non fonctionnelles aussi sérieusement que les fonctionnelles. Exécutez des tests de performance et de charge contre une demande de pointe réaliste — relèves d'équipe, connexions du lundi matin, une panne régionale redirigeant le trafic — car un système clinique qui ralentit sous charge a échoué quand cela compte le plus. Incluez le test de sécurité et le test d'accessibilité contre les Web Content Accessibility Guidelines (WCAG) comme types de test permanents et non optionnels. Les défauts non fonctionnels sont faciles à reporter et coûteux à découvrir en production.

5. Automatisez le test d'accessibilité, puis vérifiez-le avec des personnes. Les vérifications WCAG automatisées attrapent une fraction significative des problèmes (étiquettes manquantes, mauvais contraste, structure) à moindre coût à chaque construction, mais elles manquent celles qui comptent le plus pour les véritables utilisateurs de technologie d'assistance. Associez le scan automatisé au test manuel par des personnes utilisant des lecteurs d'écran, la navigation au clavier seul, et le grossissement. L'accessibilité est une obligation légale pour les organismes publics et une question de sécurité clinique lorsque l'utilisateur exclu est un clinicien ou un patient gérant ses propres soins.

6. Menez le test d'acceptation utilisateur avec de vrais cliniciens dans des conditions réalistes. Programmez l'UAT avec les véritables personnes qui utiliseront le système — infirmières, médecins généralistes, administrateurs, pharmaciens — exerçant de véritables flux de travail, idéalement dans un cadre qui reflète le service ou la clinique, pas une salle de réunion calme. Leur retour attrape les incompatibilités de flux de travail dangereuses (un avertissement montré au mauvais moment, un défaut qui invite à l'erreur) que les tests unitaires ne peuvent pas. Budgétez du temps de remplacement clinique afin que l'UAT soit fait correctement, pas pressé dans la bonne volonté.

7. Rendez la définition de terminé et les portes de qualité explicites et appliquées. Convenez de ce que « terminé » signifie pour votre contexte — tests réussis, conformité d'accessibilité, scan de sécurité propre, révision de sécurité clinique complète, documentation mise à jour — et appliquez-le comme une porte, pas un souhait. Une définition de terminé écrite mais routinièrement levée sous pression d'échéance est pire qu'aucune, car elle blanchit un travail dangereux comme complet. Les portes devraient être automatisées là où possible afin qu'elles ne puissent pas être discrètement sautées.

8. Triage et gérez les défauts avec la gravité clinique à l'esprit. Évaluez chaque défaut non seulement pour la gravité technique mais pour l'impact clinique et la probabilité, en utilisant le même prisme de risque que votre registre des dangers. Un bogue cosmétique peut attendre ; un défaut qui pourrait contribuer à une mauvaise dose bloque la mise en production quelle que soit la date de mise en production. Maintenez un registre de défauts visible, et soyez honnête sur les problèmes connus livrés comme des risques acceptés et atténués plutôt que cachés.

9. Intégrez les tests dans le pipeline de livraison, pas après lui. Câblez les tests automatisés, le scan de sécurité, et les vérifications d'accessibilité dans le pipeline d'intégration et de livraison continues afin que chaque changement soit testé avant de pouvoir progresser (voir Sujet 3.5 — Cycles de vie de livraison). Cela rend la qualité continue et bon marché, et cela signifie que la capacité de déployer un correctif testé rapidement — elle-même un contrôle de sécurité — est toujours disponible. Les phases de test manuelles de fin de projet sont lentes, tardives, et la première chose sacrifiée quand le temps manque.

Questions à discuter avec votre équipe#

1. Si nous changeons une chose dans notre système clinique en direct demain, à quel point sommes-nous confiants que nous le découvririons — avant qu'un patient ne le fasse — si cela cassait autre chose ? Cette question sonde la maturité de vos tests de régression et l'honnêteté de vos affirmations de sécurité. La plupart des incidents logiciels cliniques graves ne sont pas des échecs nouveaux exotiques mais des régressions : un changement qui a discrètement cassé un comportement que tout le monde supposait stable, découvert seulement lorsqu'un clinicien ou patient l'a rencontré. Une bonne discussion retrace un véritable changement récent jusqu'aux tests qui auraient attrapé une régression, et demande si les dangers les plus élevés du registre des dangers DCB0129/0160 sont chacun soutenus par un test automatisé qui échoue lorsque le danger réapparaît. La tension à faire surgir est entre la pression de livrer des correctifs rapidement et la discipline de prouver que rien d'autre n'a été cassé — et si votre pipeline rend cette preuve automatique ou la laisse à quelqu'un qui se souvient de vérifier. Considérez combien de temps prend votre suite de tests à s'exécuter, si elle s'exécute à chaque changement, et si quelqu'un a discrètement désactivé des tests échouants pour atteindre une échéance. Une réponse honnête distingue « nous avons une suite de régression liée à nos dangers cliniques et lui faisons confiance » de « nous testons le changement que nous avons fait et espérons le meilleur ». Si la réponse est la seconde, vous portez un risque clinique que vous ne pouvez pas voir.

2. D'où viennent nos données de test, et un test pourrait-il jamais exposer les informations d'un véritable patient ? Les environnements de test sont une voie courante et sous-examinée vers une violation de données, car les équipes sous pression saisissent les données réalistes les plus faciles — une copie de la production — et les dossiers patients qui en résultent se trouvent alors dans des systèmes de test, ordinateurs portables, ou environnements de fournisseurs moins protégés. Cette question demande à l'équipe de retracer chaque environnement de test et de mise en scène jusqu'à sa source de données, et de confronter honnêtement si les copies « juste cette fois » de données en direct sont devenues routinières. Le compromis à débattre est le réalisme contre la sécurité : les données synthétiques et anonymisées sont plus sûres mais peuvent manquer les cas limites désordonnés que les données réelles contiennent, tandis que les données en direct sont réalistes mais une responsabilité de gouvernance et de violation, et la véritable anonymisation est plus difficile qu'il n'y paraît car les dossiers peuvent être réidentifiés lorsqu'ils sont combinés. Les angles concrets incluent qui peut accéder aux environnements de test, si les bases de données de test sont chiffrées et auditées comme la production, et si les environnements de test de vos fournisseurs respectent la même barre. Une réponse forte décrit une stratégie délibérée — données synthétiques par défaut, anonymisation faite correctement, données en direct seulement comme exception documentée, minimisée, limitée dans le temps — plutôt qu'un accident attendant une enquête de gouvernance de l'information.

3. Lorsque la date de mise en production et la barre de qualité entrent en collision, qu'est-ce qui cède réellement — et qui décide ? Chaque livraison finit par faire face au moment où les tests ne sont pas terminés, un défaut est non résolu, ou la conformité d'accessibilité est incomplète, et la date de lancement approche ; comment votre organisation se comporte à ce moment révèle si la qualité est un véritable contrôle ou simplement aspirationnelle. Cette question demande à l'équipe de se rappeler la dernière fois que cela s'est produit et de décrire honnêtement ce qui a été coupé : était-ce le carnet cosmétique, ou était-ce le test de régression, l'UAT, ou l'audit d'accessibilité ? La tension est réelle et ne devrait pas être balayée — les dates comptent, les cycles de financement sont impitoyables, et des tests sans fin peuvent eux-mêmes être un mode d'échec — mais la résolution doit être gouvernée par le risque clinique et d'équité, pas par qui crie le plus fort. Discutez de qui a l'autorité de retenir un lancement pour des raisons de qualité sans risque de carrière, si votre définition de terminé est jamais formellement levée et par qui, et si les défauts connus livrés à la mise en production sont enregistrés comme des risques acceptés ou discrètement enterrés. Une bonne réponse montre une voie de décision claire et nommée, une ligne nette en dessous de laquelle un défaut bloque la mise en production quelle que soit la date (tout ce qui pourrait contribuer à un préjudice patient), et une culture où dire « pas encore, ce n'est pas sûr » est récompensé plutôt que puni.

4. Nos tests couvrent-ils réellement les choses qui pourraient nuire à un patient, ou juste les choses faciles à tester ? Une construction verte n'est rassurante que si les tests derrière exercent les véritables dangers cliniques, et il est étrangement courant qu'un chiffre de couverture d'apparence saine repose sur une suite qui vérifie des getters et setters triviaux tandis que le score de détérioration, la correspondance d'identité, et l'affichage des allergies restent non testés. Cette question demande à l'équipe de tenir la suite de tests contre le registre des dangers DCB0129/0160 et les parcours utilisateurs à plus haut risque et de demander, danger par danger, « quel test nommé échouerait si cela tournait mal ? » La tension est que les métriques de couverture récompensent le volume, pas la pertinence du risque, et les équipes sont tentées de poursuivre un pourcentage plutôt que de confronter les cas gênants et difficiles à automatiser — valeurs limites, entrées manquantes, combinaisons cliniques inhabituelles — qui sont exactement là où les patients sont blessés. Les angles concrets incluent réviser si les cas limites et frontières sont testés, si le test exploratoire et clinique (le jugement que les machines ne peuvent pas remplacer) a une place aux côtés de l'automatisation, et si quelqu'un a jamais retracé un véritable incident jusqu'à une lacune que les tests auraient dû attraper. Une réponse honnête parle de couverture pondérée par le risque et peut nommer les tests gardant les dangers principaux, plutôt que de citer un simple pourcentage comme s'il s'agissait d'une assurance.

5. Lorsque nous testons l'accessibilité, de véritables utilisateurs handicapés et de véritables cliniciens sont-ils dans la pièce, ou seulement un scanner automatisé ? Les vérifications WCAG automatisées sont bon marché et ont leur place à chaque construction, mais elles ne détectent qu'une fraction des obstacles qui excluent réellement les gens, et un service peut réussir chaque règle automatisée tout en restant inutilisable avec un lecteur d'écran ou au clavier seul. Cette question demande si votre test d'accessibilité et d'acceptation utilisateur atteint de véritables personnes utilisant la technologie d'assistance et de véritables cliniciens travaillant à travers de véritables flux de travail, ou si « nous avons testé l'accessibilité » signifie discrètement « le scanner était vert ». Le compromis à faire surgir est le coût et la logistique contre l'honnêteté : recruter des utilisateurs de technologie d'assistance et remplacer du temps clinique pour un UAT réaliste est coûteux et facile à sauter, pourtant le sauter est comment une obligation légale est violée et comment une incompatibilité de flux de travail dangereuse — un avertissement au mauvais moment, un défaut qui invite à l'erreur — atteint un service en direct. Discutez de qui vous impliquez, à quel point ils sont représentatifs, si le test se déroule dans un cadre qui reflète la clinique plutôt qu'une salle de réunion calme, et ce que vous faites de ce qu'ils trouvent. Une réponse forte décrit des vérifications automatisées associées à un test manuel par des utilisateurs handicapés et un UAT mené par des cliniciens comme une pratique permanente et budgétée, pas une case cochée une fois avant la mise en production.

6. Lorsqu'un changement traverse une frontière entre notre système et celui de quelqu'un d'autre, qui teste la jointure — et le saurions-nous si elle se cassait ? Les services modernes de santé et d'action sociale sont des assemblages de systèmes intégrés — un EPR, un service national spine, un flux de pathologie, un module d'un fournisseur tiers — et les défauts les plus dangereux vivent souvent non pas à l'intérieur d'un composant unique mais dans les coutures entre eux, où un changement d'un côté d'une interface casse discrètement l'autre. Cette question demande à l'équipe de cartographier ses intégrations critiques et de demander, pour chacune, qui possède le test de bout en bout, quelles données synthétiques circulent à travers la frontière, et comment un changement cassant dans la version d'un fournisseur serait détecté avant qu'il n'atteigne les patients. La tension est qu'aucune équipe unique ne se sent entièrement responsable d'une interface partagée, les contrats et comités consultatifs de changement se déplacent à des vitesses différentes, et tester à travers les frontières organisationnelles est lent, politique, et facile à laisser au hasard. Les angles concrets incluent les tests de contrat et d'interface, les environnements de test partagés, comment les notifications de changement de fournisseur sont gérées, et si votre suite de régression exerce le parcours intégré (orientation envoyée, reçue, reconnue) et pas seulement votre propre moitié. Une réponse honnête nomme qui est responsable de chaque jointure et montre un mécanisme — automatisé là où possible — qui attrape une régression transfrontalière, plutôt que de supposer que l'autre partie l'a couvert.

En pratique : un exemple de santé et d'action sociale#

Un trust de soins aigus du NHS déploie un nouveau module d'observations électroniques et de score d'alerte précoce (EWS) au sein de son dossier de santé électronique, remplaçant les graphiques papier sur lesquels les infirmières enregistrent les signes vitaux et le système calcule un score de détérioration. Le danger clinique est évident : un score erroné pourrait signifier qu'un patient en détérioration n'est pas escaladé.

L'équipe construit la pyramide dès le départ. Les tests unitaires couvrent le calcul EWS contre les règles de notation nationales, y compris les cas limites (les seuils exacts où un score bascule vers l'escalade) et les entrées gênantes (fréquence respiratoire manquante, un patient sous oxygène supplémentaire). Les tests d'intégration confirment que le score circule correctement vers l'alerte d'escalade et la liste de tâches infirmières. Un petit ensemble de tests de bout en bout exerce le parcours complet depuis la saisie au chevet jusqu'à une alerte déclenchée. Chaque danger du registre des dangers DCB0160 est mappé à des tests nommés, et la suite entière s'exécute automatiquement à chaque changement dans le pipeline d'intégration continue.

Les environnements de test sont provisionnés avec des patients synthétiques — schémas de signes vitaux réalistes incluant des trajectoires de détérioration — de sorte qu'aucun véritable dossier ne quitte jamais la production. Le test de performance simule une tournée de service complète à la relève d'équipe, confirmant que les alertes se déclenchent en quelques secondes sous charge de pointe. Le test d'accessibilité, automatisé à chaque construction et vérifié manuellement avec une infirmière utilisant le grossissement d'écran, attrape une bannière d'alerte à faible contraste.

L'UAT sur un service pilote, avec de vraies infirmières travaillant à travers des scénarios simulés, fait émerger un défaut de flux de travail qu'aucun développeur n'avait vu : la boîte de dialogue de confirmation apparaissait après le score, tentant le personnel de la rejeter réflexivement. L'équipe reconçoit le flux et ajoute un test de régression. À la mise en production, trois défauts cosmétiques sont livrés comme problèmes documentés et acceptés ; deux qui touchaient le calcul ont été corrigés et ont bloqué la mise en production jusqu'à ce qu'ils réussissent, et le dossier de sécurité cite directement la preuve de test. Six mois dans l'exploitation en direct, un changement routinier à la liste de tâches déclenche un test de régression qui aurait, non détecté, supprimé une alerte d'escalade — attrapé dans le pipeline, corrigé avant déploiement, n'atteignant jamais un service.

Angles sectoriels#

Startup#

Une petite entreprise de santé numérique a l'avantage de construire les tests automatisés et l'intégration continue dans son ADN dès le premier jour, sans processus de test manuel hérité à démêler, et peut atteindre une itération rapide et sûre qu'un grand trust envierait. Le danger est de traiter les tests comme un luxe à reporter en poursuivant l'adéquation produit-marché, et de lésiner sur les tests non fonctionnels et de sécurité clinique qu'aucun client précoce n'exige encore. Le fondateur doit se rappeler que les obligations DCB0129 s'attachent au fabricant quelle que soit la taille de l'entreprise, donc la preuve de régression derrière une affirmation de sécurité n'est pas optionnelle même pré-revenu. Les données de test synthétiques sont aussi une amie de la startup : elles évitent le fardeau de gouvernance de traiter de vraies données patient avant que l'entreprise n'ait les contrôles pour le faire en toute sécurité.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, ou une clinique monosite — achète habituellement ses systèmes cliniques plutôt que de les construire, donc son travail de test est l'acceptation, pas la construction : confirmer que la mise à jour d'un fournisseur ou une nouvelle intégration fonctionne toujours en toute sécurité dans le véritable flux de travail avant que le personnel n'en dépende. Avec peu ou pas de capacité informatique dédiée, la discipline pratique est une courte liste de contrôle reproductible exécutée contre les parcours à plus haut risque (réservation, prescription, enregistrement des observations) après chaque changement de fournisseur, idéalement dans un environnement de test ou de formation avec des patients synthétiques plutôt que des dossiers en direct. Les mêmes obligations de sécurité de déploiement DCB0160 et d'accessibilité s'appliquent qu'à un grand trust, mais sans l'équipe de test, donc le mouvement réaliste est de s'appuyer sur l'assurance du fournisseur tout en conservant la poignée de vérifications d'acceptation locales que seul vous pouvez faire — cela correspond-il à comment cette clinique fonctionne réellement ? Un petit prestataire qui saute même cela et teste les changements directement sur de vrais patients est à une mauvaise mise à jour d'un incident de sécurité qu'il n'a aucun moyen d'attraper.

Entreprise#

Un trust du NHS ou un fournisseur majeur exploite les tests à l'échelle et sous pleine assurance : environnements de test dédiés, UAT formel avec remplacement clinique, test d'acceptation opérationnel, test de pénétration de sécurité, et comités consultatifs de changement contrôlant les mises en production vers les systèmes cliniques en direct. Le défi caractéristique est l'héritage — grands systèmes anciens avec une couverture de test automatisée mince, où chaque changement est redouté car personne n'est confiant sur ce qu'il pourrait casser, produisant des cycles de régression manuels lents et coûteux. Le mouvement stratégique est d'investir régulièrement dans la couverture de test automatisée autour des zones à plus haut risque, convertissant la peur en confiance et les mises en production lentes en rapides et sûres. Les entreprises portent aussi le fardeau de coordination des tests à travers les systèmes intégrés, où un changement dans le produit d'un fournisseur peut casser celui d'un autre.

Gouvernement#

Un organisme national livre les tests sous le Service Standard, des évaluations de service publiées, et la plus haute barre de responsabilité publique, où un échec de test dans un système national peut affecter des millions et atteindre le Parlement. Le test d'accessibilité contre WCAG est une obligation légale appliquée aux organismes du secteur public, et le test non fonctionnel à l'échelle nationale — charge, résilience, sécurité — est existentiel plutôt qu'optionnel. Le défi est de coordonner l'assurance qualité à travers de nombreux fournisseurs et services intégrés, et de tenir une définition de terminé cohérente à travers un programme tentaculaire. Les services nationaux façonnent aussi l'écosystème : les données de test, outils, et normes qu'un organisme gouvernemental mandate ou publie deviennent la norme selon laquelle les fournisseurs construisent.

Modes d'échec courants#

• La pyramide inversée. Les tests sont majoritairement des vérifications lentes, manuelles, de bout en bout ; la rétroaction est lente, la couverture est mince, et le test de régression est sauté sous pression temporelle. Antidote : investir dans une large base de tests unitaires et d'intégration automatisés rapides.
• Les tests comme phase finale. Les tests sont une étape entassée avant la mise en production et la première chose coupée quand le calendrier glisse. Antidote : décaler vers la gauche et câbler les tests dans le pipeline d'intégration continue afin qu'ils soient continus et bon marché.
• Données en direct dans les environnements de test. Les vrais dossiers patients sont copiés dans des systèmes de test moins protégés pour le réalisme, créant une violation en attente. Antidote : données synthétiques et anonymisées par défaut ; données en direct seulement comme exception gouvernée.
• Construction verte, aucune confiance. Les tests réussissent mais couvrent des trivialités tandis que les véritables dangers cliniques restent non testés. Antidote : mapper les tests explicitement au registre des dangers et aux parcours à plus haut risque.
• Accessibilité comme case à cocher automatisée. Un scan automatisé réussi est traité comme conformité tandis que de véritables utilisateurs de technologie d'assistance ne sont jamais impliqués. Antidote : associer les vérifications automatisées au test manuel par des utilisateurs handicapés.
• La définition de terminé levée. « Terminé » est défini mais routinièrement outrepassé sous pression d'échéance, lançant un travail dangereux comme complet. Antidote : automatiser les portes et donner à quelqu'un l'autorité de retenir un lancement pour des raisons de qualité.

Modèle de maturité#

Liste de contrôle#

• Une pyramide de tests existe : large couverture unitaire/d'intégration automatisée, peu de tests de bout en bout, tous exécutés en intégration continue.
• Les dangers les plus élevés du registre des dangers DCB0129/0160 sont chacun mappés à des tests de régression nommés et automatisés.
• Une suite de régression s'exécute et doit réussir avant qu'aucun changement n'atteigne un système clinique en direct.
• Les environnements de test et de mise en scène utilisent des données synthétiques ou anonymisées ; les données patient en direct ne sont jamais utilisées négligemment.
• Le test de performance et de charge est exécuté contre une demande de pointe réaliste pour les parcours cliniques critiques.
• Le test de sécurité et le test d'accessibilité WCAG (automatisé plus manuel avec des utilisateurs de technologie d'assistance) sont des types de test permanents.
• Le test d'acceptation utilisateur est mené avec de vrais cliniciens dans des conditions réalistes, avec du temps de remplacement budgété.
• Une définition de terminé et des portes de qualité appliquées existent et ne sont pas discrètement levées sous pression d'échéance.
• Les défauts sont triés par impact clinique, et les problèmes connus livrés à la mise en production sont enregistrés comme des risques acceptés et atténués.
• La preuve de test est citée directement dans le rapport de dossier de sécurité clinique.

Sources clés#

• NHS England Digital — DCB0129 and DCB0160 clinical risk management standards; hazard log and clinical safety case report.
• NHS England — NHS Service Standard and NHS Digital Service Manual (accessibility, testing, and operating a reliable service).
• GOV.UK Service Manual (Government Digital Service) — testing, test data and environments, accessibility, and continuous delivery guidance.
• W3C Web Accessibility Initiative — Web Content Accessibility Guidelines (WCAG) 2.2 and testing techniques.
• NHS England — Digital Technology Assessment Criteria (DTAC), including clinical safety, technical assurance, and usability/accessibility.
• ISTQB (International Software Testing Qualifications Board) — foundational testing terminology and test levels.
• Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018.
• Mike Cohn — the test pyramid concept; Martin Fowler / Continuous Delivery (Humble & Farley) — test automation and CI/CD practice.

Références#

1. Software testing — Wikipédia — https://en.wikipedia.org/wiki/Software_testing
2. Quality assurance — Wikipédia — https://en.wikipedia.org/wiki/Quality_assurance
3. Unit testing — Wikipédia — https://en.wikipedia.org/wiki/Unit_testing
4. Integration testing — Wikipédia — https://en.wikipedia.org/wiki/Integration_testing
5. Shift-left testing — Wikipédia — https://en.wikipedia.org/wiki/Shift-left_testing
6. Non-functional testing — Wikipédia — https://en.wikipedia.org/wiki/Non-functional_testing
7. Regression testing — Wikipédia — https://en.wikipedia.org/wiki/Regression_testing
8. Test automation — Wikipédia — https://en.wikipedia.org/wiki/Test_automation
9. Continuous integration — Wikipédia — https://en.wikipedia.org/wiki/Continuous_integration
10. Acceptance testing — Wikipédia — https://en.wikipedia.org/wiki/Acceptance_testing
11. Web Content Accessibility Guidelines — Wikipédia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
12. Deployment environment — Wikipédia — https://en.wikipedia.org/wiki/Deployment_environment
13. Synthetic data — Wikipédia — https://en.wikipedia.org/wiki/Synthetic_data
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
16. Testing your service, and test data and environments — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/technology
17. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/WAI/standards-guidelines/wcag/
18. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-tools/digital-technology-assessment-criteria-dtac/
19. Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — UK Government / GOV.UK — https://www.legislation.gov.uk/uksi/2018/952/contents/made
20. Continuous Delivery — Jez Humble and David Farley — https://continuousdelivery.com/