Le développement de logiciels de santé coûte plus cher et prend plus de temps au Royaume-Uni que le même travail dans tout autre secteur, et la raison n’est pas que le code soit plus difficile. C’est qu’une part substantielle du budget passe dans la preuve plutôt que dans les fonctionnalités : documentation de risque clinique, gouvernance de l’information et dossiers d’assurance qu’un acheteur réclamera avant même d’essayer le produit.

Les équipes qui ont développé ailleurs le sous-estiment systématiquement. Elles chiffrent l’application, gagnent l’affaire, puis découvrent que la couche de conformité n’est pas une phase finale mais un chantier parallèle qui doit démarrer dès le premier jour, parce qu’il contraint des décisions d’architecture coûteuses à reprendre.

Ce qui pilote réellement le coût : environ un quart à un tiers d’un projet de santé britannique va dans la sécurité clinique, la gouvernance de l’information et les preuves d’assurance plutôt que dans la fonctionnalité. La question déterminante n’est pas la complexité de votre application, mais si elle touche des données de patients, si elle influence une décision clinique et si le NHS est l’acheteur. Chacune ajoute un chantier distinct et non facultatif.

Les trois questions qui fixent votre périmètre

Avant tout chiffrage, trois choses doivent être tranchées, car elles déterminent quels régimes s’appliquent et l’écart de coût entre les réponses se compte en multiples.

Traite-t-elle des données de patients ? Si oui, le RGPD britannique s’applique avec les données de santé en catégorie particulière, et dès que le NHS est impliqué vous devrez remplir le Data Security and Protection Toolkit . Ce référentiel est une auto-évaluation annuelle sur un ensemble de normes défini, et sa version actuelle s’appuie sur le Cyber Assessment Framework du National Cyber Security Centre plutôt que sur les anciennes normes autonomes. C’est une contrainte d’ingénierie réelle et non un exercice de formulaire, car elle touche au contrôle d’accès, à la journalisation, au chiffrement et à la gestion des fournisseurs.

Influence-t-elle une décision clinique ? Si oui, la gestion du risque clinique s’applique, et c’est le chantier le plus souvent oublié. DCB0129 est la norme pour les fabricants de systèmes informatiques de santé et DCB0160 son pendant pour les organisations qui les déploient. Les deux font l’objet d’une revue nationale , avec une consultation publique ouverte le 29 juin 2026 et close le 11 septembre 2026, les détails peuvent donc évoluer. Ce qui n’évoluera pas, c’est l’exigence elle-même, ni la nécessité d’un responsable de sécurité clinique nommé, doté d’un profil clinique adapté, qui tient le registre des risques et signe le dossier de sécurité.

Est-elle un dispositif médical ? Un logiciel peut l’être, et la MHRA publie des orientations sur le logiciel et l’IA comme dispositif médical . Si votre produit diagnostique, surveille, prédit ou traite, il peut relever du régime des dispositifs médicaux et exiger une évaluation de conformité par un organisme agréé britannique, ce qui représente un coût distinct et un calendrier distinct compté en mois plutôt qu’en semaines. Se tromper de classification dans un sens ou dans l’autre coûte cher, et il vaut mieux payer un avis réglementaire tôt que le découvrir pendant l’appel d’offres.

DTAC, et ce qui a changé en 2026

Si vous vendez au NHS, les Digital Technology Assessment Criteria sont le premier obstacle. Ils réunissent sécurité clinique, protection des données, sécurité technique, interopérabilité et ergonomie dans une évaluation unique que les organisations du NHS utilisent pour juger les fournisseurs.

NHS England a publié un formulaire actualisé le 24 février 2026, et les organisations devaient y basculer au 6 avril 2026, date après laquelle la version précédente n’était plus acceptée. La refonte était une simplification. Le formulaire comporte environ un quart de questions en moins, surtout en supprimant les doublons avec le Data Security and Protection Toolkit et le Pre-Acquisition Questionnaire, et l’exigence que le responsable de sécurité clinique nommé ait suivi une formation NHS Digital spécifique ne s’applique plus. Les cinq domaines d’évaluation eux-mêmes sont inchangés, leurs exigences ayant été modernisées.

Le point important pour tout chiffrage est que DTAC ne se remplit pas après coup. Il demande des preuves qui doivent avoir été produites pendant le développement. Un fournisseur qui y pense quand le premier établissement NHS le lui demande passera deux à trois mois à reconstituer de la documentation, et une partie des réponses exigera des changements de code.

La question du dispositif médical

Pour tout ce qui approche du logiciel dispositif médical, la position britannique bouge encore et mérite d’être comprise avant d’arrêter une stratégie de marché.

La Grande-Bretagne reconnaît actuellement les dispositifs marqués CE dans le cadre de dispositions transitoires, avec des échéances au 30 juin 2028 pour les dispositifs certifiés sous les anciennes directives et au 30 juin 2030 pour ceux certifiés sous les règlements européens relatifs aux dispositifs médicaux et aux diagnostics in vitro. Environ neuf dispositifs sur dix présents sur le marché britannique portent un marquage CE et non UKCA. En février 2026, la MHRA a ouvert une consultation proposant de repousser la première échéance au 31 décembre 2028 et de rendre indéfinie la reconnaissance des dispositifs marqués CE conformes au droit européen, en supprimant entièrement l’échéance de 2030. Cette consultation s’est close en avril 2026 et le résultat est attendu plus tard dans l’année.

En pratique, pour une équipe produit britannique, la tendance va vers l’alignement plutôt que la divergence, mais rien n’est acté. Si votre accès au marché dépend du marquage retenu, cette décision devrait être réexaminée quand le résultat de la consultation tombera plutôt que fixée maintenant. Notez aussi que les organismes agréés britanniques constituent une liste distincte des organismes notifiés européens, et que la capacité des deux a été un goulet persistant.

Ce que cela coûte

Les coûts de développement britanniques suivent la même structure que les autres logiciels sur mesure, avec une prime de conformité par-dessus.

Un outil ciblé au périmètre étroit, sans aide à la décision clinique et sans passage par les achats du NHS, se situe entre £15,000 et £35,000. Pensez à une interface de réservation et de dossiers pour une clinique privée, ou à un portail patient connecté à un logiciel de gestion de cabinet existant.

Une application substantielle avec un vrai travail d’intégration, de la gouvernance de l’information et un dossier DTAC coûte £35,000 à £75,000. C’est la fourchette courante pour un produit destiné à être vendu à des établissements NHS ou à un groupe de prestataires privés, et le chantier de conformité en représente une part notable.

Au-delà de £75,000, vous êtes en territoire entreprise, avec documentation de sécurité clinique, gestion formelle des risques, interopérabilité avec les normes nationales et souvent un parcours d’évaluation de conformité. Les produits de cette fourchette atteignent régulièrement £250,000 et plus, et le calendrier est piloté par l’assurance plutôt que par l’ingénierie.

Les taux journaliers suivent le marché plus large, à £75 à £150 de l’heure selon l’ancienneté, mais les projets de santé portent deux rôles absents des projets ordinaires. Un responsable de sécurité clinique est une nomination spécialisée, généralement à temps partiel, et un responsable de la gouvernance de l’information est soit un recrutement soit un consultant sous contrat. Budgétez les deux dès le départ. Notre guide du coût du développement logiciel sur mesure détaille comment les heures de développement sous-jacentes se répartissent habituellement.

Où les projets de santé échouent

Rarement sur le code. Les échecs récurrents sont structurels et prévisibles.

La conformité traitée comme une phase. Les équipes la placent après le développement et découvrent que les décisions sur la résidence des données, la journalisation et le contrôle d’accès ont déjà été prises d’une façon que le processus d’assurance n’acceptera pas. Les défaire coûte cher.

Pas de responsable de sécurité clinique avant que les achats ne le demandent. Le registre des risques est censé être un document vivant construit en parallèle du développement. En reconstituer un après coup produit un document manifestement reconstitué, et les évaluateurs NHS expérimentés le repèrent immédiatement.

L’intégration supposée simple. Se connecter aux systèmes cliniques existants est généralement le plus long poste du planning, et obtenir l’accès à un environnement de test peut prendre plus de temps que d’écrire l’intégration. Cela se confirme avant la signature du contrat, pas après.

La sécurité traitée comme une case à cocher. Les données de santé sont une cible de grande valeur et les régimes d’assurance le reflètent. Les tests d’intrusion se planifient et se budgètent, ils ne se découvrent pas. Nos conseils sur les audits de sécurité de site web couvrent la base, mais les systèmes cliniques appellent un engagement plus profond qu’une application commerciale classique.

Choisir un prestataire

Le facteur différenciant n’est pas de savoir si une agence a déjà construit un logiciel de santé. C’est de savoir si elle a mené un produit à travers un processus d’assurance et peut vous montrer les livrables.

Demandez à voir un registre des risques anonymisé et un dossier de sécurité clinique. Un prestataire qui l’a fait les possède. Un prestataire qui ne l’a pas fait décrira le processus en termes généraux et changera de sujet.

Demandez qui est leur responsable de sécurité clinique et si cette personne est salariée ou engagée au projet. Les deux réponses sont acceptables. Ne pas en avoir ne l’est pas.

Interrogez-les précisément sur DTAC et sur le fait d’avoir travaillé avec la version introduite en février 2026. La refonte est assez récente pour qu’un prestataire décrivant encore l’ancien formulaire vous dise quand il a fait cela pour la dernière fois.

Demandez comment ils aborderaient la question de la classification en dispositif médical pour votre produit. Vous ne cherchez pas une réponse définitive, ce serait en soi un signal d’alerte. Vous cherchez la preuve qu’ils savent que la question existe et quand faire intervenir un spécialiste réglementaire. Notre guide sur le choix d’une agence de développement logiciel couvre la diligence commerciale qui vaut pour tout projet.

Cadrer le périmètre avant de vous engager

L’erreur la plus coûteuse de ce secteur est de s’engager sur un prix fixe pour un périmètre dont on n’a pas encore établi quels régimes s’appliquent. Les questions de classification en tête de cet article font varier le coût d’un facteur cinq, et elles se répondent dans une courte phase de cadrage plutôt qu’en devinant.

Mecanik construit des applications contraintes par la conformité via notre équipe de développement logiciel , la gouvernance de l’information et l’assurance sécurité étant portées par les mêmes personnes qui écrivent le code plutôt que greffées par un cabinet séparé. Si vous cadrez un produit de santé et n’êtes pas encore certain de laquelle des trois questions vous concerne, c’est la conversation à avoir en premier.

Articles en relation: Agents IA en entreprise : coûts et échecs , Sites web médicaux et de santé au Royaume-Uni 2026 .

Questions fréquentes

Pourquoi le développement de logiciels de santé coûte-t-il plus cher au Royaume-Uni ? Environ un quart à un tiers du budget passe dans la documentation de sécurité clinique, la gouvernance de l’information et les preuves d’assurance plutôt que dans la fonctionnalité. Ce sont des chantiers parallèles qui contraignent l’architecture dès le premier jour, et non des phases à ajouter à la fin.

Qu’est-ce que le DTAC et quand s’applique-t-il ? Les Digital Technology Assessment Criteria constituent l’évaluation utilisée par les organisations du NHS pour juger les fournisseurs numériques, couvrant sécurité clinique, protection des données, sécurité technique, interopérabilité et ergonomie. NHS England a publié un formulaire actualisé le 24 février 2026, devenu la seule version acceptée à partir du 6 avril 2026, avec environ un quart de questions en moins.

Ai-je besoin d’un responsable de sécurité clinique ? Si votre logiciel influence une décision clinique, oui. DCB0129 s’applique aux fabricants de systèmes informatiques de santé et DCB0160 aux organisations qui les déploient, et les deux exigent un responsable de sécurité clinique nommé, au profil clinique adapté, qui tient le registre des risques et signe le dossier de sécurité. Les deux normes sont en revue, avec une consultation du 29 juin au 11 septembre 2026.

Mon logiciel est-il un dispositif médical ? Peut-être, s’il diagnostique, surveille, prédit ou traite. Cette classification déclenche une évaluation de conformité par un organisme agréé britannique, ce qui ajoute des mois et du coût. La Grande-Bretagne reconnaît actuellement les dispositifs marqués CE jusqu’au 30 juin 2028 et au 30 juin 2030, et une consultation de la MHRA close en avril 2026 proposait de repousser la première échéance et de rendre indéfinie la reconnaissance des dispositifs conformes au droit européen.

Combien coûte un logiciel de santé prêt pour le NHS ? Un outil au périmètre étroit sans aide à la décision clinique coûte £15,000 à £35,000. Une application substantielle avec intégration, gouvernance de l’information et dossier DTAC coûte £35,000 à £75,000. Les produits entreprise avec gestion formelle du risque clinique et évaluation de conformité démarrent à £75,000 et dépassent régulièrement £250,000.