Sujet 3.2 — Systèmes de conception et prototypage

Un système de conception transforme les bonnes décisions de conception en infrastructure partagée et réutilisable — afin que l'accessibilité, la sécurité clinique, et la cohérence soient intégrées une fois et héritées partout, au lieu d'être rediscutées et recassées sur chaque écran.

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

Dans la santé et l'action sociale, l'interface est souvent les derniers centimètres entre une décision clinique et un patient. Un champ de médication déroutant, un sélecteur de date inaccessible, un bouton qui signifie « annuler le rendez-vous » dans un service et « annuler et perdre vos données » dans un autre — ce ne sont pas des problèmes cosmétiques. Ce sont des problèmes de sécurité patient, des problèmes d'équité, et des problèmes de confiance. Lorsque chaque équipe conçoit ses propres composants à partir de zéro, les défauts se multiplient et les garanties de sécurité deviennent impossibles à raisonner à travers un portefeuille.

Un système de conception est comment vous arrêtez de payer pour les mêmes erreurs de manière répétée. Lorsqu'un composant accessible et bien testé est construit une fois et réutilisé à travers des dizaines de services, vous corrigez un défaut d'accessibilité ou une ambiguïté de sécurité en un seul endroit et chaque service hérite du correctif. L'alternative — des interfaces sur mesure partout — signifie une qualité inconnue et inégale : certains services respectent les Web Content Accessibility Guidelines (WCAG) et d'autres excluent discrètement précisément les personnes qui dépendent le plus des services de santé publics.

La cohérence est aussi une question de compréhension. Les patients et le personnel se déplacent entre les services — une application du National Health Service (NHS), un portail de consultations externes d'un trust, un outil de réservation d'un cabinet de médecine générale — et chaque schéma non familier impose une charge cognitive. Dans une population qui inclut des personnes malades, anxieuses, âgées, exclues numériquement, ou utilisant une technologie d'assistance, cette charge n'est pas répartie uniformément. Les modèles partagés la réduisent pour tout le monde. Ce sujet porte sur la machinerie — composants, modèles, tokens, prototypes, et opérations de conception — qui rend la conception sûre, accessible, et cohérente le chemin de moindre résistance plutôt qu'un acte d'héroïsme.

Concepts fondamentaux#

Un système de conception est une source unique de vérité pour les composants réutilisables, modèles, styles, et directives utilisés pour construire un ensemble de services numériques. C'est plus qu'un guide de style : il associe des composants fonctionnels et codés avec le raisonnement de conception, les notes d'accessibilité, et les directives d'usage qui vous disent quand et comment utiliser chacun. Les deux exemples publics les plus pertinents sont le système de conception du NHS (maintenu par NHS England, construit sur le front-end NHS.UK) et le GOV.UK Design System, maintenu par le Government Digital Service (GDS). Les deux sont ouverts, gratuitement disponibles, et éprouvés à travers des millions d'interactions.

Une bibliothèque de composants contient les blocs de construction discrets — boutons, champs de formulaire, en-têtes, résumés d'erreur — tandis qu'une bibliothèque de modèles contient les solutions d'ordre supérieur aux problèmes récurrents : comment demander une date de naissance, comment structurer une page de questions, comment signaler une erreur, comment demander à un utilisateur son numéro NHS. Les composants sont le vocabulaire ; les modèles sont les phrases. Les deux s'appuient sur l'ingénierie logicielle basée sur les composants, où les systèmes sont assemblés à partir de parties faiblement couplées, testables indépendamment, et réutilisables.

Les tokens de conception sont les plus petites décisions partagées exprimées comme des variables nommées — une couleur, une unité d'espacement, une taille de police, un contour d'état de focus. Parce que les tokens sont référencés par nom plutôt que codés en dur, un changement à un token (disons, augmenter la taille minimale de cible tactile ou le contraste) se propage de manière cohérente à chaque composant qui l'utilise. Les tokens sont le mécanisme qui maintient un système cohérent à mesure qu'il s'étend, et qui rend possible de thématiser un système partagé pour un usage local sans le forker.

Une source unique de vérité est l'idée directrice : chaque décision de conception est maîtrisée en exactement un endroit, afin qu'elle ne puisse pas dériver hors synchronisation à travers les services. Lorsque la conception, le code, et les directives pour un composant vivent tous dans une bibliothèque faisant autorité, vous éliminez la classe de bogues où l'image et le produit sont en désaccord.

Le prototypage logiciel est la pratique consistant à construire des versions délibérément incomplètes d'un service pour apprendre quelque chose avant de vous engager à construire la vraie chose. Les prototypes vont de la faible fidélité (croquis papier, wireframes en niveaux de gris) à la haute fidélité (interactifs, réalistes, souvent construits en code). Le principe du GDS est prototyper pour apprendre, pas pour garder : le travail d'un prototype est de répondre à une question par des tests d'utilisabilité avec de vrais utilisateurs, après quoi il est jeté — c'est du prototypage jetable (ou « rapide »), distinct d'un prototype évolutif que vous avez l'intention de consolider en production.

Les DesignOps (opérations de conception) sont la discipline consistant à exploiter la conception à l'échelle — les personnes, flux de travail, gouvernance, modèle de contribution, et outillage qui maintiennent un système de conception partagé sain, financé, et fiable à travers une organisation ou un integrated care system (ICS). C'est pour la conception ce que l'ingénierie de plateforme est pour le code : majoritairement invisible quand cela fonctionne, douloureusement évident quand ce n'est pas le cas. Le prototypage se fait dans des outils de conception tels que Figma ou directement en code en utilisant le front-end d'un système de conception, ce qui nous amène au développement web front-end — la couche HTML, CSS, et JavaScript où la réutilisation réduit réellement la duplication, le coût, et le risque.

Ce sujet ne recouvre délibérément pas ce dont les utilisateurs ont besoin (voir Sujet 3.0 — Recherche utilisateur et conception de services) ni comment les mots sont écrits (voir Sujet 3.1 — Conception de contenu et littératie en santé). Ces disciplines alimentent le système de conception ; ce sujet porte sur la machinerie réutilisable qui porte leurs conclusions en toute sécurité vers la production.

Bonnes pratiques#

1. Adoptez avant de construire. Partez du système de conception du NHS et du GOV.UK Design System plutôt que d'inventer le vôtre. Ils encodent déjà des années de tests d'accessibilité, de conception de contenu, et d'usage réel à travers les services de santé et gouvernementaux. Réinventer un sélecteur de date ou un résumé d'erreur n'est pas un bon usage d'une capacité de conception et d'ingénierie rare et coûteuse, et une version maison sera presque toujours moins accessible. Étendez et thématisez ces systèmes pour les besoins locaux ; ne les forkez pas sans une raison délibérée et documentée.

2. Intégrez l'accessibilité et la sécurité clinique dans les composants partagés, pas les écrans individuels. Tout le dossier économique et de sécurité pour un système de conception est que vous corrigez quelque chose une fois et l'héritez partout. Un composant de date de naissance accessible, navigable au clavier, testé avec un lecteur d'écran, construit et assuré une fois, protège chaque service qui l'utilise. Intégrez la conformité WCAG, la gestion sensée des erreurs, et les comportements pertinents pour la sécurité (confirmation claire des actions destructrices, unités non ambiguës pour les doses et mesures) dans le composant lui-même, afin que les équipes ne puissent pas facilement se tromper (voir Sujet 1.9 — Inclusion numérique et accessibilité, et Sujet 1.6 — Sécurité clinique et gestion des risques).

3. Prototypez pour apprendre, pas pour garder. Traitez les prototypes comme des expériences jetables qui répondent à une question spécifique — « un patient ayant une faible littératie en santé peut-il compléter cette orientation ? » — à moindre coût et rapidement. Adaptez la fidélité à la question : utilisez des croquis à faible fidélité pour tester le flux et la compréhension tôt, et des prototypes codés à haute fidélité pour tester l'interaction réaliste, l'accessibilité, et les cas limites plus tard. Résistez à l'attraction de promouvoir un prototype directement en production ; le code de prototype optimisé pour la vitesse d'apprentissage est rarement assez sûr, sécurisé, ou maintenable pour un service clinique en direct.

4. Prototypez dans le vrai front-end lorsque l'interaction et l'accessibilité sont la question. Les prototypes d'outils de conception (Figma et similaires) sont excellents pour explorer la mise en page, le flux, et le contenu rapidement et de manière collaborative. Mais ils ne peuvent pas tester fidèlement la navigation au clavier, le comportement du lecteur d'écran, la gestion du focus, ou la performance sur du matériel ancien du parc NHS. Lorsque ce sont les risques, prototypez en code en utilisant le front-end du système de conception, afin de tester quelque chose de proche de ce que de vrais utilisateurs vivront réellement avec de vraies technologies d'assistance.

5. Testez les prototypes avec de vrais utilisateurs avant de construire. Un prototype qui n'est jamais placé devant des utilisateurs représentatifs n'est qu'une opinion coûteuse. Testez avec des personnes qui reflètent votre population réelle — incluant des personnes âgées, des personnes handicapées, des personnes à faible confiance numérique, et du personnel travaillant sous pression temporelle. Même cinq participants feront émerger la plupart des problèmes sérieux d'utilisabilité et de compréhension, et les trouver dans un prototype est des ordres de grandeur moins coûteux que de les trouver en production (voir Sujet 3.7 — Tests et assurance qualité).

6. Gérez les tokens comme le contrat de cohérence. Exprimez les couleurs, l'espacement, la typographie, et les états d'interaction comme des tokens de conception nommés, et traitez les changements qui leur sont apportés avec le sérieux d'un changement de dépendance partagée. Les tokens vous permettent d'appliquer le contraste minimum, la taille de cible tactile, et la visibilité du focus à l'échelle du système, et permettent à une équipe locale de re-thématiser pour sa marque sans casser les garanties d'accessibilité sous-jacentes. Lorsqu'une norme nationale change, vous voulez changer un token, pas auditer dix mille écrans.

7. Exploitez un modèle de contribution, pas un jardin clos. Un système de conception qui n'accepte que les contributions d'une équipe centrale sera toujours en retard sur les besoins réels de service et sera ressenti négativement par les équipes de livraison. Publiez une voie claire pour que les équipes proposent de nouveaux composants et modèles, avec des critères pour ce qui est accepté, qui le révise, et comment l'accessibilité et la sécurité sont assurées avant que quoi que ce soit soit promu dans la bibliothèque partagée. C'est un travail DesignOps central : il équilibre la tension entre la flexibilité locale et la cohérence partagée sans laisser le système pourrir ou se fragmenter.

8. Versionnez, documentez, et communiquez les changements. Traitez le système de conception comme un produit avec des utilisateurs (vos équipes de livraison), une feuille de route, des notes de version, et un canal de support. Le versionnage sémantique, les journaux de changements, et des avis de dépréciation clairs permettent aux équipes d'adopter les améliorations en toute sécurité et selon leur propre calendrier. Des changements cassants non documentés détruisent la confiance qui fait que les équipes choisissent le système partagé plutôt que de construire le leur.

9. Mesurez l'adoption et la qualité, pas seulement l'existence. Un système de conception ne livre de la valeur que lorsqu'il est utilisé. Suivez quels services utilisent les composants partagés, où les équipes ont dû construire des alternatives sur mesure (et pourquoi), et si la conformité d'accessibilité s'améliore à mesure que l'adoption augmente. Des taux élevés de solutions de contournement locales sont un signal que le système manque quelque chose de réel — traitez-les comme du carnet, pas comme de la désobéissance.

Questions à discuter avec votre équipe#

1. Où devrait se situer la ligne entre la cohérence partagée et la flexibilité locale, et qui décide ? C'est la tension de gouvernance centrale de tout système de conception. Trop rigide, et les équipes de livraison se sentent bloquées, construisent des composants fantômes, et contournent le système — fragmentant la cohérence même que vous essayiez de protéger. Trop lâche, et le « système » devient un tas de solutions ponctuelles vaguement liées sans garanties partagées de sécurité ou d'accessibilité. Dans un contexte de santé et d'action sociale, les enjeux sont spécifiques : certaines variations sont légitimes (un service de crise de santé mentale a des besoins véritablement différents d'un réservateur de rendez-vous de routine), tandis que certaines variations sont dangereuses (façons incohérentes de confirmer une action clinique destructrice). Une bonne réponse nomme quelles décisions sont non négociables (accessibilité, modèles critiques pour la sécurité, comportements d'interaction fondamentaux) et lesquelles sont ouvertes à la thématisation locale, et elle définit un processus explicite et humain pour qu'une équipe demande une exception ou contribue un nouveau modèle plutôt que d'interdire simplement la divergence.

2. Comment l'accessibilité et la sécurité clinique seront-elles réellement assurées à l'intérieur de nos composants — et qui les valide ? Il est facile de revendiquer que l'accessibilité et la sécurité sont « intégrées » ; il est difficile de le garantir. Cette question vous force à être concret sur le pipeline d'assurance : qui teste chaque composant contre WCAG, avec quelles technologies d'assistance, et avec quels utilisateurs handicapés ; comment les comportements pertinents pour la sécurité sont révisés contre votre processus de sécurité clinique (DCB0129/DCB0160) ; et quelle preuve est attachée à un composant avant qu'il ne soit publié comme « sûr à réutiliser ». Le débat devrait faire émerger des lacunes honnêtes — peut-être avez-vous des vérifications de contraste automatisées mais n'avez jamais testé avec un véritable utilisateur de lecteur d'écran, ou votre responsable de sécurité clinique n'a jamais révisé la bibliothèque de composants partagés. Une réponse forte produit un propriétaire nommé, un régime de test défini, et une règle qu'aucun composant n'entre dans la bibliothèque partagée sans preuve documentée d'accessibilité et de sécurité, car un défaut hérité par cinquante services est cinquante fois le préjudice.

3. Qui finance, dote en personnel, et maintient le système de conception une fois que l'enthousiasme initial s'estompe ? Les systèmes de conception sont fréquemment créés dans une rafale d'énergie puis discrètement abandonnés lorsque l'équipe fondatrice passe à autre chose, laissant une bibliothèque périmée à laquelle les équipes ne font plus confiance. C'est fondamentalement une question de DesignOps et de financement, pas une question de conception. Débattez honnêtement de si vous avez une équipe permanente et financée responsable du système comme un produit continu — avec une capacité de support, de révision de contribution, de versionnage, et de maintien du rythme avec les systèmes NHS et GOV.UK en amont — ou si vous comptez sur une bonne volonté qui s'évaporera. Dans un ICS, cela est encore plus aigu : le système est-il possédé par une organisation dominante, gouverné conjointement, ou orphelin entre elles ? Une bonne réponse traite le système de conception comme une infrastructure de longue durée avec un propriétaire nommé, un budget courant, et une relation claire avec les systèmes nationaux sur lesquels il s'appuie, plutôt qu'un projet qui « se termine ».

4. Quelle est notre relation avec les systèmes NHS et GOV.UK en amont — et comment resterons-nous en phase avec eux à mesure qu'ils changent ? Adopter un système de conception national n'est pas un téléchargement ponctuel ; c'est une dépendance continue envers une infrastructure que vous ne contrôlez pas. Cette question vous force à décider, délibérément, où vous vous situez sur le spectre allant de « thématiser légèrement et suivre l'amont de près » à « forker et diverger ». Chaque choix a un coût : rester proche signifie absorber les changements en amont (un nouveau correctif d'accessibilité, un modèle révisé) selon le calendrier de quelqu'un d'autre et retravailler occasionnellement les personnalisations locales ; forker signifie que vous possédez chaque futur correctif d'accessibilité et de sécurité que l'équipe nationale vous aurait autrement donné gratuitement. Dans la santé et l'action sociale, l'attraction vers la divergence est réelle — les flux de travail cliniques et l'image de marque locale créent une véritable pression — mais chaque divergence est un passif permanent. Une bonne réponse nomme qui surveille les notes de version en amont, comment les extensions locales sont structurées pour survivre à une mise à jour en amont, et le test explicite qu'une divergence proposée doit passer avant d'être autorisée, afin que « nous avions besoin que ce soit différent » ne devienne jamais discrètement « nous maintenons maintenant un fork périmé et moins accessible du sélecteur de date du NHS ».

5. Comment maintiendrons-nous réellement la ligne entre « prototyper pour apprendre » et « construire pour garder » ? Tout le monde est d'accord en principe que les prototypes jetables ne devraient pas devenir des services de production ; l'échec se produit sous pression d'échéance, lorsqu'un prototype convaincant à haute fidélité est là, tout prêt, et le livrer ressemble à un raccourci. Cette question rend la frontière concrète plutôt qu'aspirationnelle. Débattez de ce qui empêche pratiquement le code de prototype — optimisé pour la vitesse d'apprentissage, pas pour la sécurité, la résilience, ou la maintenabilité — d'être promu dans un service clinique en direct : est-ce une séparation technique (prototypes construits dans un bac à sable qui ne peut atteindre la production), une porte de gouvernance (aucune validation de sécurité clinique, aucune mise en production), ou simplement une bonne intention partagée qui s'évapore la première fois qu'une date de livraison glisse ? Les enjeux de santé et d'action sociale sont spécifiques, car un code non assuré dans un parcours clinique est une exposition de sécurité patient, pas seulement de la dette technique. Une réponse honnête admet d'où viendra la pression, nomme qui est habilité à dire non, et définit ce que « reconstruire pour la production à partir de composants assurés » exige réellement afin que la frontière tienne lorsqu'elle est testée.

6. Comment saurons-nous si le système de conception fonctionne réellement — et que ferons-nous lorsque les métriques sont inconfortables ? Un système de conception peut exister, être magnifiquement documenté, et pourtant livrer peu de valeur si les équipes le contournent discrètement. Cette question pousse au-delà de « nous avons un système de conception » vers « gagne-t-il sa place ». Décidez ce que vous mesurerez : l'adoption à travers les services, le taux et les raisons des solutions de contournement sur mesure, si la conformité d'accessibilité s'améliore réellement à mesure que l'adoption augmente, et combien de temps les équipes économisent en réutilisant plutôt qu'en reconstruisant. La partie difficile n'est pas de collecter les chiffres mais de convenir à l'avance de comment vous les lirez — car un taux élevé de solutions de contournement locales est un signal que le système partagé manque quelque chose de réel, pas une preuve que les équipes de livraison sont désobéissantes. Une bonne réponse s'engage à traiter les données d'adoption inconfortables comme une entrée de carnet et de feuille de route, définit qui les révise et à quelle fréquence, et résiste à la tentation de ne mesurer que la chose flatteuse (existence, nombre de téléchargements) plutôt que la chose qui compte (des services plus sûrs, plus accessibles, plus cohérents réellement livrés).

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

Un integrated care system couvrant trois trusts de soins aigus, un trust de santé mentale, et un prestataire communautaire décide de consolider son parc numérique orienté patient. Aujourd'hui, chaque organisation exploite son propre portail de consultations externes ; entre elles, elles ont quatre sélecteurs de date incompatibles, trois façons différentes de demander un numéro NHS, et une conformité d'accessibilité extrêmement variable. Un audit interne constate qu'un seul des quatre portails réussit un test de base de lecteur d'écran de son flux de réservation de rendez-vous — une exposition claire d'équité et de sécurité clinique.

L'ICS met en place une petite équipe de système de conception financée conjointement. Plutôt que de construire à partir de zéro, elle adopte le système de conception du NHS comme fondation et définit une fine couche locale de tokens de conception pour l'image de marque spécifique à l'ICS, plus une poignée de modèles véritablement locaux (par exemple, un modèle partagé pour réserver un soutien d'interprète, que aucun des systèmes nationaux ne couvre). Chaque composant partagé porte une preuve documentée de conformité WCAG et une validation du responsable de sécurité clinique de l'ICS au titre du processus DCB0129 avant d'être publié.

Avant de reconstruire le flux de réservation de consultations externes, l'équipe prototype. Elle commence à faible fidélité, testant une version papier et en niveaux de gris du nouveau flux avec douze participants recrutés pour refléter la population locale — incluant deux utilisateurs de lecteur d'écran, trois personnes de plus de 75 ans, et plusieurs à faible confiance numérique. Le prototype expose un problème sérieux de compréhension : les patients ne peuvent pas distinguer une action « reprogrammer » d'une action « annuler ». L'équipe corrige le modèle, puis construit un prototype codé à haute fidélité en utilisant le front-end du système de conception et le retest, cette fois confirmant le comportement du clavier et du lecteur d'écran sur le matériel réel utilisé dans les cliniques de consultations externes d'un trust partenaire.

C'est seulement alors qu'elle construit pour de vrai, assemblant le service de production largement à partir de composants assurés et réutilisables. Dix-huit mois plus tard, une mise à jour WCAG resserre les exigences de visibilité du focus. Parce que le style de focus vit dans un token de conception unique, l'équipe livre un seul changement et chaque service de l'ICS l'hérite dans la prochaine version — un correctif qui, sous l'ancien parc fragmenté, aurait signifié cinq projets de remédiation séparés et, réalistement, au moins un service laissé cassé.

Angles sectoriels#

Startup#

Une petite startup de santé numérique ne devrait presque jamais construire son propre système de conception à partir de zéro — elle ne peut pas se permettre la charge de test d'accessibilité, et les investisseurs paient pour la validation clinique, pas des boutons sur mesure. Adoptez le front-end du NHS ou du GOV.UK là où vous construisez pour des utilisateurs NHS, et traitez le prototypage comme votre avantage compétitif central : des prototypes bon marché, rapides, jetables testés avec de vrais patients vous permettent d'apprendre plus vite que des acteurs établis mieux financés. Le risque est l'opposé — promouvoir un prototype élégant à haute fidélité directement en production pour atteindre une démo d'investisseur, portant du code non assuré et non sécurisé dans un service clinique en direct. Gardez une ligne dure entre « prototyper pour apprendre » et « construire pour garder », même sous pression de financement.

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 commissionnant un outil orienté patient — a de vrais patients mais aucune capacité de conception ou de front-end dédiée, et ne peut pas absorber le coût de composants sur mesure. Son mouvement le plus puissant est d'insister pour que tout fournisseur construise sur le front-end du NHS ou du GOV.UK, afin que les garanties d'accessibilité et de sécurité soient héritées plutôt que promises, et d'en faire une condition écrite du contrat plutôt qu'un espoir. Elle a rarement besoin d'exploiter son propre système de conception ; elle a besoin d'en consommer un bien, et de reconnaître qu'une démo élégante d'un fournisseur n'est pas la preuve d'un service en direct accessible et assuré. Là où elle prototype effectivement — testant un nouveau flux de réservation en ligne avec ses vrais patients, souvent plus âgés ou moins confiants numériquement — quelques sessions avec de vrais utilisateurs révéleront bien plus qu'une maquette soignée ne révélera jamais. Les mêmes obligations statutaires d'accessibilité et de sécurité clinique s'appliquent que pour un grand trust, donc la question honnête n'est pas de savoir s'il faut se conformer mais comment obtenir une conformité héritée à moindre coût depuis une infrastructure nationale partagée.

Entreprise#

Un grand trust du NHS ou une entreprise de health-tech a déjà de multiples équipes construisant des interfaces qui se chevauchent, donc son problème est la fragmentation et le coût dupliqué. Le dossier de valeur est une équipe de système de conception financée et permanente exploitant un véritable modèle de contribution, avec des métriques d'adoption rapportées à la direction et une ligne de gouvernance claire vers l'assurance de sécurité clinique et d'accessibilité. La tension centrale est politique : des équipes de livraison puissantes résistent à céder le contrôle, et une équipe centrale à la main lourde engendre des composants fantômes. Les entreprises réussissent en rendant le système partagé le choix véritablement plus facile — bien documenté, bien soutenu, et démontrablement de meilleure qualité — plutôt qu'en le mandatant et en espérant.

Gouvernement#

Un organisme national tel que NHS England ou GDS exploite le système de conception comme une infrastructure publique utilisée par des organisations qu'il ne contrôle pas, donc l'ouverture, la stabilité, et la rétrocompatibilité comptent énormément. Ses obligations sont les plus fortes : réglementations d'accessibilité statutaires, obligations d'égalité, et la réalité qu'un défaut dans un composant national partagé se propage à des millions de citoyens. Le travail concerne moins l'invention et plus l'intendance — versionnage clair, politique de dépréciation, preuve d'accessibilité exhaustive, et réactivité envers les centaines d'équipes en aval. Le système de conception du NHS et le GOV.UK Design System sont les exemples de référence précisément parce qu'ils traitent le système comme un bien public de longue durée, pas un projet.

Modes d'échec courants#

• Le système abandonné. Un système de conception est construit en fanfare, puis laissé non maintenu lorsque l'équipe fondatrice se disperse ; les équipes perdent confiance et dérivent vers un travail sur mesure. Évitez cela en finançant une équipe produit permanente, pas un projet ponctuel.
• L'image qui ment. Les fichiers de conception et le code de production sont en désaccord parce qu'il n'y a pas de source unique de vérité, donc « le système de conception » décrit quelque chose que le produit ne fait plus. Gardez les composants codés et leur documentation faisant autorité et versionnés ensemble.
• Accessibilité en réflexion après coup. Des composants sont livrés sans véritable test de technologie d'assistance, donc un modèle inaccessible est hérité partout — multipliant, pas réduisant, le préjudice. Exigez une preuve documentée WCAG et de lecteur d'écran avant que tout composant ne soit publié.
• Prototype vers production. Un prototype à haute fidélité est promu directement dans un service en direct pour gagner du temps, portant du code non sécurisé, non maintenable, non assuré dans un contexte clinique. Appliquez la frontière du jetable ; reconstruisez pour la production à partir de composants assurés.
• Le jardin clos. Une équipe centrale refuse toutes les contributions, donc le système ne répond jamais aux véritables besoins de service et les équipes de livraison le contournent. Publiez un processus de contribution et d'exception et traitez les solutions de contournement locales comme un signal de carnet.
• Théâtre de la cohérence. Une uniformité rigide est imposée là où une véritable variation locale est justifiée (services de crise, pédiatrie), dégradant la sécurité et l'utilisabilité au nom de l'ordre. Distinguez les décisions non négociables de celles légitimement locales.
• Tester la mauvaise fidélité. Les risques d'interaction et d'accessibilité sont « testés » seulement dans un outil de conception statique qui ne peut pas exercer le comportement du clavier ou du lecteur d'écran, donnant une fausse confiance. Prototypez en code lorsque l'interaction est la question.

Modèle de maturité#

Liste de contrôle#

• Vous avez adopté le système de conception du NHS et/ou le GOV.UK Design System comme fondation plutôt que de construire à partir de zéro.
• Les composants partagés portent une preuve documentée de conformité WCAG, testée avec une vraie technologie d'assistance et des utilisateurs handicapés.
• Les composants pertinents pour la sécurité ont été révisés sous votre processus de sécurité clinique avant d'être publiés pour réutilisation.
• Les tokens de conception gouvernent la couleur, l'espacement, la typographie, et les états d'interaction, permettant des changements à l'échelle du système depuis un seul endroit.
• Il y a une source unique de vérité où les composants codés et leurs directives vivent et sont versionnés ensemble.
• Les prototypes sont adaptés en fidélité à la question, testés avec un échantillon d'utilisateurs représentatif, et traités comme jetables.
• Les flux critiques pour l'interaction et l'accessibilité sont prototypés en code, pas seulement dans un outil de conception.
• Une équipe financée et nommée possède le système de conception comme un produit continu, avec une feuille de route et un canal de support.
• Un processus publié de contribution et d'exception permet aux équipes de livraison de proposer de nouveaux composants et modèles.
• L'adoption et la qualité sont mesurées, et des taux élevés de solutions de contournement locales sont traités comme du carnet, pas de la désobéissance.

Sources clés#

• NHS design system — NHS England: components, patterns, styles, and accessibility guidance for NHS digital services.
• GOV.UK Design System — Government Digital Service: styles, components, and patterns for UK government services.
• GOV.UK Service Manual — prototyping and "make a prototype" — Government Digital Service: guidance on prototyping to learn and testing with users.
• NHS Digital Service Standard — NHS England: the standard shared and consistent services are assessed against.
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative: the accessibility conformance standard.
• Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — UK government: the statutory accessibility duty for public sector services.
• DCB0129 / DCB0160 Clinical Risk Management standards — NHS England: clinical safety standards for the manufacture and deployment of health IT systems.
• Design Council Double Diamond — Design Council: the discover–define–develop–deliver model underpinning discovery and design.

Références#

1. Design system — Wikipédia — https://en.wikipedia.org/wiki/Design_system
2. Software prototyping — Wikipédia — https://en.wikipedia.org/wiki/Software_prototyping
3. Single source of truth — Wikipédia — https://en.wikipedia.org/wiki/Single_source_of_truth
4. Usability testing — Wikipédia — https://en.wikipedia.org/wiki/Usability_testing
5. GOV.UK (and the GOV.UK Design System) — Wikipédia — https://en.wikipedia.org/wiki/GOV.UK
6. Government Digital Service — Wikipédia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Web Content Accessibility Guidelines — Wikipédia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
8. Component-based software engineering — Wikipédia — https://en.wikipedia.org/wiki/Component-based_software_engineering
9. Figma — Wikipédia — https://en.wikipedia.org/wiki/Figma
10. Front-end web development — Wikipédia — https://en.wikipedia.org/wiki/Front-end_web_development
11. NHS design system — NHS England — https://service-manual.nhs.uk/design-system
12. GOV.UK Design System — Government Digital Service — https://design-system.service.gov.uk/
13. Make a prototype — GOV.UK Service Manual — https://www.gov.uk/service-manual/design/making-prototypes
14. NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
15. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/TR/WCAG22/
16. Understanding accessibility requirements for public sector bodies — GOV.UK — https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
17. Clinical Risk Management: its Application in the Manufacture of Health IT Systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation-for-clinical-risk-management-standards