Sujet 3.5 — Cycles de vie de livraison

En une phrase : Un cycle de vie de livraison est la séquence de phases et de portes de décision — Découverte, Alpha, Bêta, En direct, et retrait éventuel — à travers laquelle un service numérique se déplace, avec la sécurité clinique, la gouvernance de l'information, et l'assurance tissées à travers chaque phase plutôt qu'ajoutées à la fin.

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

Un cycle de vie est comment une organisation convertit une idée en un service sûr et en direct et, éventuellement, le retire de manière responsable. Dans la santé et l'action sociale, chaque transition porte un poids statutaire et clinique : vous ne pouvez pas déployer un système qui touche les soins aux patients sans un dossier de sécurité clinique, et vous ne pouvez pas traiter des données confidentielles de patients sans une base légale et une évaluation d'impact relative à la protection des données (DPIA) complétée. Un cycle de vie qui traite ceux-ci comme de la paperasse de fin de projet produit des services qui sont en retard, dangereux, ou les deux.

Les enjeux sont asymétriques. Une application grand public qui livre un bogue agace les utilisateurs ; un dossier de soins partagé qui livre un bogue peut montrer à un clinicien les allergies du mauvais patient. C'est pourquoi le NHS intègre le modèle de phase du GOV.UK et les normes de gestion du risque clinique DCB0129 et DCB0160 dans le même cycle de vie. Bien faire le cycle de vie n'est pas une gentillesse de gouvernance — c'est le mécanisme par lequel la sécurité, l'équité, et le rapport qualité-prix de l'argent public sont réellement livrés plutôt que simplement promis.

Les dirigeants ont aussi besoin du cycle de vie car il rend les progrès lisibles. Des phases et portes nommées permettent à un conseil d'administration de voir où en est un service, quelle preuve existe, et quelle décision est due — remplaçant le brouillard du « c'est presque fini » par un engagement défendable et échelonné d'argent public.

Concepts fondamentaux#

Le modèle de phase : Découverte → Alpha → Bêta → En direct. Les normes de service du NHS et du GOV.UK définissent quatre phases. La Découverte (voir Sujet 3.4 — Phases de découverte) comprend le problème. L'Alpha construit des prototypes jetables pour tester si une solution pourrait fonctionner et pour réduire les hypothèses les plus risquées. La Bêta construit le véritable service, d'abord privé puis public, sur une infrastructure de production, itérant avec de vrais utilisateurs à une échelle croissante. En direct exploite le service en fonctionnement continu, itérant toujours, jusqu'à son retrait. Les phases sont une rampe de réduction de risque : chaque phase engage plus d'argent et expose plus d'utilisateurs, justifiée par la preuve de la précédente.

Itération continue, pas une chaîne de montage. Les phases ne sont pas une cascade à sens unique. Un service en bêta peut boucler en arrière vers l'alpha pour une fonctionnalité difficile ; un service en direct itère continuellement. La valeur du modèle réside dans ses portes, pas dans une promesse que le travail circule dans une seule direction.

Agile, cascade, et hybride. La cascade (waterfall) fixe le périmètre en amont et procède en séquence — adaptée seulement là où les exigences sont véritablement stables et connaissables (une migration de centre de données, un changement réglementaire mandaté). L'agile livre en petits incréments, inspectant et adaptant — adaptée à l'incertitude des services orientés utilisateur. L'hybride est la réalité honnête de la plupart des grands programmes de santé : des équipes produit agiles opérant à l'intérieur d'une enveloppe de jalons et de financement que l'organisation et ses régulateurs exigent. Adaptez la méthode à l'incertitude, pas à la mode.

Évaluations de service et portes de normes. Aux transitions entre phases — en particulier alpha vers bêta et avant le lancement public — les services NHS et GOV.UK font face à une évaluation de service : un panel indépendant testant le travail contre les points du Service Standard (besoin utilisateur, accessibilité, sécurité, fiabilité, équipe, choix technologiques). Réussir est la porte pour dépenser plus et exposer plus d'utilisateurs. L'évaluation est une revue par les pairs fondée sur des preuves, pas un tampon automatique.

La sécurité clinique et la gouvernance de l'information comme fils du cycle de vie. DCB0129 (pour le fabricant/fournisseur) et DCB0160 (pour l'organisation de santé ou d'action sociale déployante) exigent un système de gestion du risque clinique, un registre des dangers, et un rapport de dossier de sécurité clinique validé par un responsable de sécurité clinique (CSO) nommé et formé. La gouvernance de l'information exige une base légale, une DPIA, et l'adhérence aux principes Caldicott. Les deux sont des fils qui traversent la découverte, l'alpha, la bêta, et le direct — pas des portes à la fin.

Le désengagement (decommissioning). Un cycle de vie a une fin. Retirer un service en toute sécurité — migrer ou archiver les données selon le droit de conservation, rediriger les utilisateurs, notifier les cliniciens, et préserver les dossiers — est une phase à part entière, et l'une des plus négligées.

Bonnes pratiques#

1. Utilisez les phases comme des portes de réduction de risque, pas des jalons de calendrier. Laissez la décision de chaque phase être « y a-t-il assez de preuve pour justifier l'engagement de la prochaine tranche d'argent et d'utilisateurs ? » Une phase qui se termine parce que la date est arrivée, plutôt que parce que la preuve est là, a manqué le point de la porte.

2. Tissez la sécurité clinique dès l'alpha, pas avant le Direct. Nommez un responsable de sécurité clinique et ouvrez le registre des dangers dès qu'une forme de solution existe. Les dangers identifiés en alpha sont bon marché à concevoir en dehors ; les dangers trouvés à la mise en production sont une crise bloquant le lancement. Le dossier de sécurité mûrit aux côtés du service, donc la validation DCB0129/0160 est un résumé du travail déjà fait, pas une précipitation.

3. Commencez le travail de DPIA et de gouvernance de l'information en découverte et gardez-le vivant. Les flux de données, la base légale, et les considérations Caldicott façonnent l'architecture, donc faites-les émerger pendant que l'architecture est encore malléable. Une DPIA écrite après la construction est un exercice de documentation ; une écrite aux côtés de la conception réduit réellement le risque et évite le retravail.

4. Automatisez le chemin vers la production avec CI/CD et DevOps. L'intégration continue et la livraison continue — pipelines automatisés de construction, test, et déploiement — permettent à une équipe de livrer des changements petits et réversibles en toute sécurité et fréquemment. Dans un domaine critique pour la sécurité, la capacité de déployer un correctif en quelques minutes et de revenir en arrière proprement est en soi un contrôle de sécurité. Associez cela à la surveillance, aux alertes, et à l'infrastructure en tant que code afin que le service en direct soit observable et reproductible.

5. Adaptez la méthode à l'incertitude. Utilisez l'agile là où les besoins utilisateurs sont incertains et où la découverte vous enseigne encore des choses ; acceptez le séquençage type cascade seulement là où les exigences sont véritablement fixes et où le risque de changement est faible. Soyez explicite sur l'exploitation d'un hybride — équipes agiles à l'intérieur d'une enveloppe de programme — plutôt que de prétendre qu'une méthode gouverne tout, ce qui ne trompe personne et frustre tout le monde.

6. Traitez l'évaluation de service comme un outil de conception, pas un examen. Amenez les réviseurs d'assurance, de sécurité clinique, de sécurité, et d'accessibilité tôt et souvent, afin que l'évaluation formelle confirme un service déjà construit selon la norme. Les équipes qui rencontrent la norme pour la première fois la semaine avant l'évaluation échouent lentement et coûteusement ; les équipes qui l'internalisent réussissent comme sous-produit.

7. Continuez à itérer en Direct — et dotez-le en ressources. Un service n'arrête pas d'avoir besoin d'une équipe une fois en direct. Le Direct est là où l'usage réel expose les dernières inégalités, les cas limites cliniques rares mais graves, et les lacunes d'accessibilité. Financez une équipe produit permanente pour la vie opérationnelle du service (voir Sujet 5.0 — Travail piloté par le produit) ; un service en direct sans équipe est de la dette technique accumulant du risque clinique.

8. Planifiez le désengagement avant d'en avoir besoin. Décidez, en construisant, comment le service sera éventuellement retiré : conservation et migration des données selon le droit de gestion des dossiers, redirection des utilisateurs, notification des cliniciens, et archivage du dossier de sécurité clinique et de la piste d'audit. Un retrait non planifié échoue les données et les utilisateurs ; un retrait planifié est une phase contrôlée et auditable.

Questions à discuter avec votre équipe#

1. Nos portes de phase sont-elles véritablement gouvernées par la preuve, ou sont-elles discrètement devenues des dates sur un plan ? Toute la valeur du modèle Découverte–Alpha–Bêta–Direct est que chaque transition engage plus d'argent et expose plus d'utilisateurs seulement lorsque la preuve de la phase précédente le justifie ; au moment où une porte se déclenche parce que le trimestre s'est terminé plutôt que parce que la preuve est là, la rampe cesse de réduire le risque et devient de la « cascade déguisée en agile ». Cette question demande à une équipe de regarder honnêtement ses dernières transitions et de demander ce qui se serait passé si la preuve avait dit « pas encore » — y avait-il de la place pour attendre, boucler une bêta en arrière vers l'alpha pour une fonctionnalité difficile, ou la date de mise en production était-elle politiquement immuable ? La tension à débattre est entre le besoin de l'organisation en jalons lisibles et programmés par le conseil d'administration et la réalité que des services sûrs se déplacent au rythme de la preuve, et la livraison hybride vit précisément dans cette friction. Les angles concrets incluent nommer la décision spécifique et la preuve due à la prochaine porte, vérifier si les « sprints » changent réellement le périmètre ou suivent simplement un plan fixe, et demander qui est habilité à retarder une porte sans risque de carrière. Une bonne réponse peut pointer vers une véritable instance où la preuve a changé le plan, et peut articuler quelle preuve justifierait — ou bloquerait — le prochain engagement d'argent public et d'utilisateurs.

2. La sécurité clinique et la gouvernance de l'information sont-elles des fils vivants à travers chaque phase, ou de la paperasse que nous prévoyons de terminer avant le Direct ? Dans la santé et l'action sociale, la DPIA et le travail de risque clinique DCB0129/0160 ne sont pas des validations de fin de projet mais des fils qui doivent façonner l'architecture et la conception dès l'alpha, car un danger conçu en dehors tôt est bon marché tandis qu'un danger découvert à la mise en production est une crise bloquant le lancement — ou pire, une pression pour laisser passer le dossier de sécurité. Cette question fait émerger si un responsable de sécurité clinique nommé et formé et un registre des dangers ouvert existent dès qu'une forme de solution apparaît, et si l'analyse de DPIA et de base légale a commencé en découverte pendant que les flux de données étaient encore assez malléables pour changer. Le compromis qui vaut la peine d'être débattu est le frein ressenti de faire cela continuellement contre le coût bien plus grand et le risque clinique d'une adaptation ultérieure, en particulier pour les petites équipes ou startups où aucun régulateur ne surveille encore mais où l'obligation DCB0129 s'attache au fabricant quelle que soit la taille de l'entreprise. Considérez la preuve concrète : le registre des dangers montre-t-il des dangers trouvés et atténués en alpha, le dossier de sécurité se lit-il comme un résumé du travail déjà fait, et la DPIA remonte-t-elle à de véritables décisions de conception ? Une réponse honnête distingue une équipe faisant mûrir son dossier de sécurité aux côtés du service d'une équipe se dirigeant vers une précipitation de documentation le mois avant le lancement.

3. Comment ce service sera-t-il exploité en Direct et éventuellement retiré — et qui est financé pour le faire ? Les cycles de vie ont une longue traîne que les organisations sous-financent régulièrement : le Direct est là où l'usage réel expose les dernières inégalités, les cas limites cliniques rares mais graves, et les lacunes d'accessibilité, et il a besoin d'une équipe produit permanente, d'une surveillance, et d'un déploiement rapide et réversible plutôt qu'une équipe qui se dissout à la mise en production, laissant le service pourrir et accumuler silencieusement du risque clinique. Également négligé est le désengagement — retirer un service selon le droit de conservation des dossiers, migrer ou archiver les données, rediriger les utilisateurs, notifier les cliniciens, et préserver le registre des dangers et la piste d'audit — ce qui pour un système national est un programme majeur en soi, pas une réflexion après coup lorsque le remplacement arrive. La tension à débattre est les cycles de financement annuels et la pression de déclarer un projet « terminé » au lancement contre l'appropriation de vie entière qu'un service sûr exige réellement. Les angles utiles incluent si un pipeline CI/CD avec surveillance et retour en arrière rapide est traité comme un contrôle de sécurité en direct, si un budget d'astreinte et d'itération survit à la célébration de mise en production, et si un plan de sortie a été écrit en construisant plutôt qu'improvisé dans la panique. Une bonne réponse nomme qui possède le service pour sa vie opérationnelle et décrit un retrait contrôlé et auditable plutôt qu'un espoir que quelqu'un s'en occupera plus tard.

4. Quand avons-nous laissé pour la dernière fois l'échec d'un prototype nous arrêter — et construisons-nous encore des choses à jeter ? L'alpha existe pour réduire les hypothèses les plus risquées à moindre coût, ce qui signifie qu'un prototype jetable qui échoue a fait son travail : il a acheté une leçon coûteuse avant que l'argent de production et de vrais patients ne soient engagés. Cette question sonde si une équipe traite véritablement l'alpha comme un apprentissage jetable ou a discrètement glissé vers le polissage de son premier prototype dans le produit éventuel parce que jeter du code semble un gaspillage — le piège du coût irrécupérable qui transforme une phase de réduction de risque en un engagement coûteux pris à l'aveugle. La tension qui vaut la peine d'être mise en évidence est la pression d' « avoir quelque chose à montrer » et de réutiliser chaque ligne écrite contre la discipline de prouver qu'une solution pourrait fonctionner avant de construire la vraie sur une infrastructure de production. Les angles concrets incluent demander quelles hypothèses la dernière alpha a réellement testées, si un prototype a déjà été abandonné sur la preuve, et si la construction de bêta privée a réutilisé du code jetable qui aurait dû être réécrit selon la norme de production. Une réponse honnête peut pointer vers une hypothèse spécifique qu'un prototype a tuée ou confirmée, et peut distinguer les artefacts d'apprentissage que l'équipe était disposée à jeter du code assuré qu'elle exploite maintenant en Direct.

5. Exploitons-nous un hybride honnête, ou plusieurs méthodes déguisées qui se contredisent discrètement ? La plupart des grands programmes de santé sont véritablement hybrides — équipes produit agiles opérant à l'intérieur d'une enveloppe de jalons et de financement que l'organisation et ses régulateurs exigent — et l'échec n'est pas l'hybride lui-même mais prétendre qu'il est purement agile ou purement cascade, de sorte que les deux logiques entrent en collision non gérées à chaque porte. Cette question demande à une équipe de nommer où les engagements fixes et séquencés se situent réellement (tranches de financement, jalons réglementaires, gels d'intégration) et où la véritable itération se produit, plutôt que de laisser « agile » et « le plan » revendiquer chacun le programme entier et frustrer tout le monde. Le compromis à débattre est le besoin légitime de l'organisation en jalons prévisibles et en dépenses auditables contre le besoin de l'équipe de livraison de changer le périmètre sur preuve, et le mouvement honnête est de rendre les coutures explicites afin que les deux puissent être planifiées autour. Les angles utiles incluent si la reprisation du carnet survit jamais au contact avec le plan de programme, si les fournisseurs sont contractés pour un périmètre fixe tout en étant priés de travailler de manière itérative, et si le rapport qu'un conseil d'administration voit correspond à comment le travail est réellement fait. Une bonne réponse décrit un hybride délibérément conçu avec des points fixes nommés et des espaces flexibles nommés, pas un embrouillamini dans lequel une méthode est revendiquée pour les apparences.

6. À quel point savons-nous bien ce qu'un service en direct fait réellement à ses utilisateurs en ce moment — et remarquerions-nous le préjudice avant qu'ils ne le signalent ? Un service de santé en direct n'est aussi sûr que son observabilité : la surveillance, les alertes, et les instincts de sécurité clinique qui transforment une métrique en danger font la différence entre attraper un défaut de données périmées en quelques minutes et l'apprendre d'un rapport d'incident des semaines plus tard. Cette question examine si l'équipe peut voir le service en production — taux d'erreur, échecs d'intégration, abandon d'accessibilité, les écarts d'équité que seul l'usage réel révèle — et si quelqu'un surveille les tableaux de bord avec le risque clinique à l'esprit, pas seulement le temps de fonctionnement de l'infrastructure. La tension est le coût et la discipline d'une observabilité et d'une astreinte appropriées contre l'hypothèse silencieuse que « pas de nouvelles, bonnes nouvelles » une fois qu'un service est en direct, ce qui dans un domaine critique pour la sécurité est comment le préjudice silencieux s'accumule. Les angles concrets incluent si le registre des dangers est mis à jour depuis les incidents en direct, si les alertes correspondent à l'impact clinique plutôt qu'uniquement à la santé du serveur, et si une mauvaise version peut être détectée et annulée avant d'atteindre de nombreux patients. Une réponse honnête décrit des signaux spécifiques que l'équipe surveille, un véritable incident que la surveillance a attrapé (ou manqué), et comment la preuve en direct se réinjecte dans la prochaine itération.

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

Un trust communautaire du NHS remplace un système hérité papier et tableur pour la planification des visites d'infirmières de district. Sortant de la découverte (Sujet 3.4), l'équipe entre en alpha et construit deux prototypes jetables pour tester les hypothèses les plus risquées : que les infirmières utiliseront un téléphone dans les foyers des patients, et que le planning peut s'intégrer avec le dossier de santé électronique. Un responsable de sécurité clinique est nommé le premier jour de l'alpha et ouvre un registre des dangers ; un danger précoce — un planning périmé montrant une visite déjà effectuée par une collègue — motive une décision de conception pour afficher un statut de synchronisation en temps réel. La DPIA, commencée en découverte, signale que les données de localisation des travailleurs isolés ont besoin d'une base légale et d'une limite de conservation définies.

À l'évaluation de service alpha vers bêta, un panel indépendant sonde l'accessibilité (infirmières ayant des déficiences visuelles), la sécurité, et le raisonnement de l'équipe. Le service réussit avec des actions. En bêta privée, dix infirmières utilisent le véritable système sur une infrastructure de production ; un pipeline CI/CD permet à l'équipe de livrer quotidiennement et de revenir en arrière sur une mauvaise version en moins de dix minutes. L'usage révèle un problème d'équité — le personnel d'agence sans appareils du trust — menant à un repli basé sur navigateur. La bêta publique s'étend à trois localités ; le rapport de dossier de sécurité clinique est complété et validé au titre du DCB0160 avant un déploiement plus large.

Le service passe En direct avec une équipe produit permanente, des tableaux de bord de surveillance, et une liste de garde. Dix-huit mois plus tard, lorsque le trust adopte une plateforme régionale, le planning est désengagé selon un plan : données migrées selon le calendrier de conservation, infirmières reformées et redirigées, et registre des dangers et dossier de sécurité archivés pour audit. Chaque transition était une décision soutenue par la preuve, pas une date sur un diagramme de Gantt.

Angles sectoriels#

Startup#

Le cycle de vie d'une startup est compressé et largement auto-gouverné : il n'y a pas de panel d'évaluation de service indépendant, donc la discipline des portes Alpha–Bêta–Direct doit être auto-imposée ou elle s'effondre en « livrer continuellement et espérer ». L'avantage est qu'une petite équipe peut exploiter un véritable CI/CD dès le premier jour et itérer plus vite que tout grand organisme. Le danger est de discrètement abandonner les fils de sécurité clinique et de DPIA car aucun régulateur ne surveille encore — une erreur fatale dans la santé, où les obligations DCB0129 s'attachent au fabricant quelle que soit la taille de l'entreprise, et un danger non géré peut mettre fin à la fois au produit et à l'entreprise. Les startups devraient adopter l'intention du modèle de phase — la preuve avant l'exposition — même sans le cérémonial, en nommant un responsable de sécurité clinique (souvent fractionnaire) dès qu'une forme de solution existe.

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 — rencontre habituellement le cycle de vie comme un déployeur plutôt qu'un constructeur : il achète ou configure le système d'un fournisseur, donc la validation de déploiement DCB0160 et une DPIA locale lui reviennent même sans équipe numérique interne. Les phases s'appliquent toujours, mais compressées et sous-traitées : l' « alpha » est un pilote supervisé sur quelques vrais patients, la « bêta » est un déploiement échelonné à travers le cabinet, et le Direct est l'activité courante avec les mises à jour du fournisseur arrivant continuellement et largement en dehors du contrôle du cabinet. L'organisation doit nommer un responsable de sécurité clinique (souvent un partenaire clinique prenant le rôle en plus d'un travail quotidien) et maintenir un registre des dangers pour comment le système est utilisé localement, car le travail DCB0129 du fabricant ne couvre pas les risques spécifiques du déploiement. Avec une trésorerie serrée et aucune informatique dédiée, la discipline réaliste est de s'appuyer sur l'assurance du fournisseur tout en possédant les quelques décisions que seule la connaissance locale peut prendre — qui est formé, quel est le repli lorsque le système est hors service, et comment les données patient circulent dans ce contexte spécifique.

Entreprise#

Un trust du NHS ou un grand fournisseur exploite le cycle de vie dans sa forme la plus complète et la plus assurée : évaluations de service formelles, un responsable de sécurité clinique nommé, validation de déploiement DCB0160, comités consultatifs de changement, et un cycle de financement annuel dans lequel le travail agile doit s'insérer. Le défi caractéristique est l'hybride — équipes de livraison agiles opérant à l'intérieur d'une enveloppe de programme et de jalons que l'organisation et ses auditeurs exigent — et l'échec classique est la « cascade déguisée en agile », où les portes deviennent discrètement des dates de calendrier. Les entreprises ont les ressources pour faire correctement le CI/CD, l'observabilité, et les équipes produit permanentes, pourtant l'inertie organisationnelle et l'intégration héritée ralentissent souvent le déploiement à un rythme d'escargot. La responsabilité est large et le rayon d'impact grand, donc la rampe échelonnée de la bêta privée au direct n'est pas une prudence optionnelle mais un contrôle de risque essentiel.

Gouvernement#

Un organisme national livre sous le Service Standard complet, des évaluations de service publiées, des contrôles de dépenses, et un examen parlementaire, donc chaque porte de phase est aussi un point de responsabilité publique. Les cycles de vie ici sont longs et l'exposition vaste — un service national du NHS en direct peut toucher des millions de personnes — ce qui élève les enjeux sur la rampe échelonnée, l'assurance de sécurité clinique, et le désengagement des systèmes hérités remplacés. Les règles d'achat et les règlements de financement pluriannuels façonnent ce que « agile » peut signifier en pratique, et retirer un système national (avec ses décennies de dossiers et obligations statutaires de conservation) est un programme majeur en soi. Le compromis est l'assurance contre la vitesse : la livraison gouvernementale est fortement contrôlée, ce qui protège la sécurité et l'argent public mais exige un effort délibéré pour garder les équipes en train d'itérer plutôt que de revenir à une grande conception initiale.

Modes d'échec courants#

• Cascade déguisée en agile. L'équipe exploite des « sprints » mais le périmètre, les dates, et la conception étaient tous fixés en amont ; l'itération est du théâtre. Antidote : laisser la preuve à chaque porte changer véritablement le plan.
• Sécurité et gouvernance de l'information ajoutées à la fin. Le dossier de sécurité clinique et la DPIA sont écrits le mois avant la mise en production, bloquant le lancement ou, pire, laissés passer sous pression. Antidote : ouvrir le registre des dangers et la DPIA en alpha et les faire mûrir continuellement.
• Le lancement big-bang. Le service saute la bêta privée/publique et passe directement au déploiement complet, exposant chaque utilisateur à un logiciel non prouvé. Antidote : utiliser la rampe échelonnée ; augmenter l'exposition avec la preuve.
• Le service en direct abandonné. L'équipe de livraison se dissout à la mise en production ; le service pourrit, et le risque clinique s'accumule silencieusement. Antidote : financer une équipe produit permanente pour la vie opérationnelle.
• Bachotage d'évaluation. Les normes sont ignorées jusqu'à ce que l'évaluation approche, puis respectées superficiellement. Antidote : engager en continu les réviseurs d'assurance et cliniques.
• Aucun plan de sortie. Le service est retiré dans la panique lorsque son remplacement arrive, échouant les données et les utilisateurs. Antidote : planifier le désengagement comme une phase de premier ordre.

Modèle de maturité#

Liste de contrôle#

• Le service a une phase actuelle explicite (Découverte / Alpha / Bêta / Direct) et une prochaine décision nommée.
• Les transitions de phase sont contrôlées sur preuve, pas sur dates.
• Un responsable de sécurité clinique est nommé et un registre des dangers est ouvert (DCB0129/0160) dès l'alpha.
• Une DPIA et une évaluation de base légale (Caldicott, UK GDPR) ont commencé en découverte et sont tenues à jour.
• La méthode de livraison est adaptée au niveau d'incertitude, et tout arrangement hybride est explicite.
• Les évaluations de service sont planifiées, et les réviseurs d'assurance/sécurité/accessibilité sont engagés tôt.
• Un pipeline CI/CD avec surveillance et retour en arrière rapide est en place avant la bêta publique.
• Le service est exposé aux utilisateurs dans une rampe échelonnée (bêta privée → bêta publique → direct), pas en big-bang.
• Une équipe produit permanente est financée pour la vie opérationnelle du service (voir Sujet 5.0).
• Un plan de désengagement couvre la conservation/migration des données, la redirection des utilisateurs, et l'archivage des dossiers de sécurité et d'audit.

Sources clés#

• GOV.UK Service Manual — the phases of an agile project (Discovery, Alpha, Beta, Live) and the Government Service Standard.
• NHS England — NHS Service Standard and NHS Digital Service Manual; NHS service assessments.
• NHS England Digital — DCB0129 (Clinical Risk Management: its Application in the Manufacture of Health IT Systems) and DCB0160 (its Application in the Deployment and Use of Health IT Systems).
• NHS England — Digital clinical safety assurance; the Clinical Safety Officer role, hazard log, and clinical safety case report.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• UK Caldicott Principles; Data Protection Act 2018 / UK GDPR and data protection impact assessments.
• NICE — Evidence Standards Framework for Digital Health Technologies.
• DevOps and continuous delivery practice (e.g. the DORA capabilities: continuous integration, deployment automation, monitoring); GOV.UK Service Manual guidance on continuous delivery and operating a service.

Références#

1. Systems development life cycle — Wikipédia — https://en.wikipedia.org/wiki/Systems_development_life_cycle
2. Waterfall model — Wikipédia — https://en.wikipedia.org/wiki/Waterfall_model
3. Agile software development — Wikipédia — https://en.wikipedia.org/wiki/Agile_software_development
4. Software prototyping — Wikipédia — https://en.wikipedia.org/wiki/Software_prototyping
5. CI/CD — Wikipédia — https://en.wikipedia.org/wiki/CI/CD
6. Continuous integration — Wikipédia — https://en.wikipedia.org/wiki/Continuous_integration
7. Continuous delivery — Wikipédia — https://en.wikipedia.org/wiki/Continuous_delivery
8. DevOps — Wikipédia — https://en.wikipedia.org/wiki/DevOps
9. Infrastructure as Code — Wikipédia — https://en.wikipedia.org/wiki/Infrastructure_as_code
10. Observability (software) — Wikipédia — https://en.wikipedia.org/wiki/Observability_(software)
11. Privacy impact assessment (data protection impact assessment) — Wikipédia — https://en.wikipedia.org/wiki/Privacy_impact_assessment
12. Agile delivery: the phases of an agile project — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/agile-delivery
13. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/
16. Continuous delivery — Jez Humble and David Farley — https://continuousdelivery.com/
17. Data protection impact assessments (DPIAs) — Information Commissioner's Office (ICO) — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/
18. Evidence standards framework for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health