Sujet 1.1 — Le modèle opérationnel

En une phrase : Un modèle opérationnel cible (TOM) est la conception délibérée de la façon dont la stratégie de votre organisation se déploie à travers des flux de valeur, des capacités, des équipes, une gouvernance, une technologie, des données et des fournisseurs pour livrer des résultats de santé et d'action sociale numériques — et bien concevoir sa forme détermine si tout ce qui suit est rapide et sûr, ou lent et fragile.

Pourquoi cela compte dans la santé et l'action sociale#

La plupart des organisations de santé numérique n'échouent pas par manque de talent ou de technologie ; elles échouent parce que leur modèle opérationnel les combat. Le financement est lié à des projets limités dans le temps, les droits de décision sont ambigus, et chaque équipe reconstruit la même plomberie de connexion, d'intégration et d'audit. Le résultat est un coût dupliqué en argent public, une sécurité clinique incohérente, et des services incapables de partager des données au sein d'un système de soins intégrés (ICS).

Un modèle opérationnel est particulier dans ce domaine parce qu'il doit concilier des biens concurrents. Il doit être assez fédéré pour respecter l'autonomie d'organisations souveraines — trusts, autorités locales, cabinets de médecine générale — tout en étant assez cohérent pour donner à un patient une seule expérience sûre à travers elles. Il doit équilibrer le maintien en condition (garder les systèmes cliniques disponibles en toute sécurité) face au changement (les améliorer), quand une indisponibilité peut affecter les soins. Et il doit dépenser proportionnellement : une assurance assez lourde pour la responsabilité publique et la sécurité clinique, assez légère pour ne pas étouffer l'itération. Le TOM est l'endroit où ces compromis sont rendus explicites plutôt que laissés au hasard.

Concepts clés#

Les couches d'un modèle opérationnel. Un TOM utile est une pile, chaque couche servant celle du dessus :

• Stratégie et résultats — les résultats mesurables de population et de service que vous existez pour améliorer (souvent exprimés sous forme d'OKR ; voir sujet 1.3 — Décisions fondées sur les preuves).
• Flux de valeur — les parcours de bout en bout qui livrent de la valeur à un utilisateur, par exemple « référer, trier et traiter un patient » — organisés autour du parcours du citoyen, pas de l'organigramme.
• Capacités — les choses que vous devez être capable de faire (identité, prise de rendez-vous, documentation clinique, analytique). Les capacités restent stables même quand les solutions changent.
• Équipes — les personnes organisées pour livrer les capacités et les flux de valeur (voir Team Topologies ci-dessous).
• Gouvernance et droits de décision — qui décide quoi, et comment l'assurance est appliquée.
• Technologie et données — les plateformes, normes et architecture de données sur lesquelles les équipes s'appuient.
• Fournisseurs — le marché auprès duquel vous achetez et comment vous le gérez.

Concevoir de haut en bas (stratégie → flux de valeur → capacités) garde les équipes et la technologie alignées sur les résultats plutôt que sur les structures héritées.

Modèles centralisé, fédéré et plateforme. Un modèle centralisé concentre la livraison dans une seule équipe ou un organisme indépendant : cohérent et peu coûteux à standardiser, mais un goulot d'étranglement et souvent éloigné du besoin local. Un modèle fédéré délègue la livraison aux trusts et aux territoires : réactif et détenu localement, mais sujet à la duplication et à la divergence. Un modèle de plateforme est le schéma de réconciliation : une équipe centrale fournit des capacités partagées et réutilisables (identité, interopérabilité, hébergement, système de conception) comme une plateforme, et les équipes fédérées construisent dessus à grande vitesse. La plupart des systèmes de santé matures convergent vers « plateforme plus fédération ».

Team Topologies. Ce cadre nomme quatre types d'équipe — alignée sur un flux (propriétaire d'un flux de valeur), plateforme (fournissant des capacités en libre-service), habilitante (accompagnant d'autres équipes vers une capacité), et sous-système complexe (travail spécialisé approfondi tel qu'un algorithme) — et insiste sur une interaction à faible friction entre elles. Il se superpose proprement au modèle de plateforme : les équipes plateforme réduisent la charge cognitive des équipes alignées sur un flux afin qu'elles puissent se concentrer sur la valeur utilisateur et clinique.

Maintien en condition contre changement. Le maintien en condition consiste à garder les services en production sûrs et disponibles ; le changement consiste à les améliorer ou à les construire. Les équipes produit qui construisent et font fonctionner un service à la fois (« vous le construisez, vous le faites fonctionner ») ferment la boucle de rétroaction et améliorent la sécurité, mais l'équilibre doit être financé honnêtement — affamer le maintien en condition pour financer le changement est ainsi que les systèmes cliniques se dégradent.

La plateforme viable la plus mince (TVP). Tirée de Team Topologies : une plateforme devrait être l'ensemble le plus petit de services partagés qui réduit véritablement la friction pour les équipes de flux — pas plus. Une plateforme surdimensionnée devient son propre goulot d'étranglement et son propre héritage. Commencez par les quelques capacités dont chaque équipe a réellement besoin (authentification, une couche d'interopérabilité, hébergement, un système de conception) et ne croissez que sur demande avérée.

Bonnes pratiques#

1. Concevez le modèle à partir des résultats vers le bas, pas de l'organigramme vers le haut. Commencez par les résultats de population et de service que vous devez faire bouger, dérivez les flux de valeur qui les livrent, et concevez seulement ensuite les équipes et la technologie. Un TOM ancré dans la hiérarchie existante ne fait qu'automatiser les silos actuels.

2. Adoptez une forme plateforme-plus-fédération. Fournissez des capacités partagées de façon centrale comme une plateforme en libre-service, et laissez les équipes alignées sur un flux dans les trusts et les territoires construire dessus. Cela vous donne une cohérence nationale sur la sécurité et l'interopérabilité avec la vitesse et l'appropriation locales — la réconciliation qu'exige le domaine.

3. Financez des produits, pas des projets. Déplacez l'argent des projets limités dans le temps vers des équipes produit financées de façon persistante et alignées sur les flux de valeur. Le financement projet force les équipes à se dissoudre exactement au moment où elles ont appris le domaine ; le financement produit soutient la connaissance de sécurité et l'itération dont les services de santé ont besoin (voir sujet 5.0 — Travail piloté par le produit).

4. Rendez le contrôle des dépenses proportionné et échelonné. Utilisez un financement échelonné lié aux preuves — libérez de l'argent aux portes de découverte, alpha, bêta et production plutôt que d'approuver tout un programme à l'avance. Les contrôles de dépenses de style GDS et le parcours d'assurance du NHS existent pour éviter de gros coûts irrécupérables sur des idées non prouvées ; appliquez-les comme des seuils calibrés au risque et à la valeur, pas comme une bureaucratie uniforme.

5. Rendez les droits de décision explicites avec une carte RACI ou RAPID. L'autorité ambiguë est la cause la plus courante de livraison bloquée. Nommez, pour chaque type de décision important, qui est Responsable/Approbateur/Consulté/Informé (RACI) ou qui Recommande, Approuve, exécute (Perform), a un avis (Input), et Décide (RAPID). Publiez-le afin que les équipes arrêtent d'escalader des décisions qu'elles sont habilitées à prendre.

6. Gardez la plateforme mince et pilotée par la demande. Construisez des capacités partagées seulement quand deux équipes ou plus ont manifestement besoin de la même chose, et traitez la plateforme comme un produit avec ses propres utilisateurs (les équipes internes). Résistez à l'envie de pré-construire une grande plateforme ; la plateforme viable la plus mince gagne son périmètre par l'adoption.

7. Gérez les fournisseurs comme faisant partie du modèle, pas en dehors de lui. Décidez délibérément quelles capacités sont stratégiques (construire/posséder) et lesquelles sont de commodité (acheter), évitez le verrouillage auprès d'un fournisseur unique sur les données cliniques essentielles, et exigez des normes ouvertes et des droits de sortie dans les contrats. Vos fournisseurs sont une couche de votre modèle opérationnel, et leurs façons de travailler doivent être compatibles avec les vôtres.

8. Rendez les droits de décision explicites. Un modèle opérationnel ne fonctionne que si les gens savent qui décide quoi — quels choix relèvent d'une équipe produit, lesquels d'une autorité de sécurité clinique, et lesquels doivent atteindre un conseil d'administration. Cartographiez les droits de décision et poussez chaque décision au niveau le plus bas capable de la porter en toute sécurité, afin que la livraison ne soit pas étranglée par une escalade inutile. L'autorité ambiguë est l'une des causes les plus courantes d'une livraison lente et défensive.

9. Traitez le modèle opérationnel comme un produit que vous faites évoluer. Un modèle opérationnel cible n'est pas fixé une fois pour toutes et encadré sur un mur ; inspectez-le à mesure que la demande, la technologie et les partenariats changent, et adaptez-le sur preuve. Surveillez quelques signaux — flux de travail, délai de décision, reprises de travail, et santé des équipes — et changez les structures quand elles gênent manifestement, pas en réponse à une mode de réorganisation.

Questions à discuter avec votre équipe#

1. Notre modèle opérationnel est-il conçu à partir des résultats et des flux de valeur vers le bas, ou a-t-il simplement automatisé notre organigramme existant et ses silos ? Cette question rejoint l'avertissement central du sujet selon lequel un TOM ancré dans la hiérarchie actuelle ne fait qu'enraciner les silos que vous avez déjà, donc elle mérite d'être mise sur la table avant toute réorganisation. Elle compte dans un contexte de santé et d'action sociale parce que les flux de valeur suivent le parcours du citoyen — référer, trier, traiter — à travers des organisations souveraines, tandis que les organigrammes suivent les frontières institutionnelles, et un modèle construit sur ces dernières continuera de produire des services fragmentés et non interopérables avec de l'argent public. Le tiraillement à débattre honnêtement est que concevoir de haut en bas à partir des résultats est véritablement perturbateur : cela coupe à travers l'appropriation départementale, les budgets et les lignes hiérarchiques sur lesquels des personnes seniors ont construit des carrières, donc il y a un vrai coût politique à bien le faire. Testez-vous concrètement en nommant vos trois principaux résultats et en retraçant si vos frontières d'équipe et lignes de financement réelles suivent ces flux de valeur ou les départements ; si les équipes correspondent proprement aux départements, voilà votre réponse. Une bonne réponse honnête admet où le modèle est façonné par l'organigramme, identifie au moins un flux de valeur actuellement scindé entre silos à son détriment, et est réaliste sur les frontières structurelles que l'organisation est prête à redessiner.

2. Que doit contenir notre plateforme viable la plus mince, et comment éviterons-nous qu'elle soit soit surconstruite en goulot d'étranglement, soit sous-construite au point que chaque équipe reconstruise la même plomberie ? La forme plateforme-plus-fédération ne fonctionne que si la plateforme reste mince et pilotée par la demande, et cette question amène l'équipe à confronter les deux modes de défaillance que le sujet nomme — la grande plateforme qui devient son propre goulot d'étranglement hérité, et son absence qui force chaque équipe à reconstruire connexion, intégration et audit. Elle compte parce que dans un ICS la plateforme est effectivement une infrastructure partagée (identité, une couche d'interopérabilité FHIR, un hébergement avec des bases de sécurité, un système de conception) et se tromper sur son périmètre multiplie soit le coût, soit la friction à travers chaque équipe de flux. Le compromis à débattre est le calendrier et la preuve : construire trop tôt et vous devinez mal et créez un goulot d'étranglement ; construire trop tard et la duplication s'est déjà figée — donc le test « deux équipes ou plus ont manifestement besoin de la même chose » est le cœur du sujet, et l'équipe devrait tester rigoureusement si elle l'applique réellement ou construit simplement ce qui semble évidemment central. Regardez ce que vous traitez actuellement comme plateforme par rapport à ce que les équipes reconstruisent, et demandez-vous si la plateforme est gérée comme un produit avec ses propres utilisateurs internes et des accords de niveau de service, ou comme une file d'attente derrière laquelle tout le monde patiente. Une réponse honnête nomme les capacités précises qui passent le test des deux équipes aujourd'hui, résiste à la tentation de pré-construire le reste, et s'engage à traiter les utilisateurs internes de l'équipe plateforme comme de vrais clients avec de vrais niveaux de service.

3. Où nos droits de décision sont-ils véritablement ambigus, et qu'est-ce que les équipes escaladent aujourd'hui qu'elles devraient être habilitées à décider elles-mêmes ? L'autorité ambiguë est désignée comme la cause la plus courante de livraison bloquée, donc cette question fait surgir la friction quotidienne qu'une carte RACI ou RAPID publiée est censée supprimer. Elle compte de façon aiguë dans un système de santé fédéré où les équipes territoriales, un conseil numérique de l'ICS, la sécurité clinique et la gouvernance de l'information ont tous des revendications légitimes sur une décision, et des frontières floues signifient soit que tout escalade, soit, pire, que personne ne possède un choix jusqu'à ce qu'il tourne mal. Le tiraillement qui vaut la peine d'être exploré est que déléguer des décisions exige de faire confiance aux équipes dans des limites claires, ce que les dirigeants seniors et les conseils d'administration résistent souvent à faire précisément là où la sécurité clinique ou l'argent public est en jeu — pourtant refuser cette confiance est ce qui crée l'embouteillage d'escalade en premier lieu. Rendez cela concret en listant les cinq dernières décisions qui ont escaladé et en demandant, pour chacune, qui aurait dû décider et quelle garde-fou l'aurait permis ; le schéma révèle généralement un petit nombre de types de décisions ambiguës récurrents. Une bonne réponse produit un énoncé précis et publiable de qui décide quoi — distinguant les normes de plateforme, la conception de service et la validation de sécurité clinique — et est honnête sur les décisions que l'organisation est véritablement prête à déléguer par rapport à celles qu'elle gardera centrales, et pourquoi.

4. Finançons-nous honnêtement le maintien en condition et le changement, ou affamons-nous discrètement les opérations de service en production pour payer de nouvelles fonctionnalités ? Le sujet est direct : affamer le maintien en condition pour financer le changement est ainsi que les systèmes cliniques se dégradent, et cette question force l'équilibre au grand jour avant qu'une panne ou un incident de sécurité ne le fasse à votre place. Elle compte dans la santé et l'action sociale parce que le « maintien en condition » n'est pas une charge administrative — c'est la disponibilité des systèmes dont les cliniciens dépendent au point de soin, donc un budget de maintien dégradé se traduit par une indisponibilité qui peut affecter les patients, pas seulement des utilisateurs contrariés. Le compromis est inconfortable parce que le changement est visible et célébré tandis que le maintien en condition est invisible jusqu'à ce qu'il échoue, donc les conseils d'administration et les feuilles de route penchent naturellement vers le nouveau ; un modèle « vous le construisez, vous le faites fonctionner » aide en gardant la boucle de rétroaction fermée, mais seulement si le temps de maintien de l'équipe est véritablement protégé plutôt qu'alloué en théorie puis pillé. Rendez cela concret en regardant quelle proportion de la capacité de chaque équipe produit est réellement allée à garder les services sûrs et disponibles le trimestre dernier par rapport à ce qui était prévu, et si le travail de maintien est suivi et valorisé ou traité comme une interruption. Une réponse honnête nomme où le maintien en condition est sous-financé aujourd'hui, protège une allocation réaliste de maintien comme une première charge plutôt qu'un résidu, et est franche sur les services en production qui portent un risque opérationnel accumulé.

5. Quelles capacités choisissons-nous délibérément de construire et de posséder par rapport à acheter, et acceptons-nous un verrouillage sur nos données cliniques essentielles sans le vouloir ? La bonne pratique ici est de décider construire contre acheter délibérément, d'éviter le verrouillage auprès d'un fournisseur unique sur les données cliniques essentielles, et de traiter les fournisseurs comme une couche du modèle opérationnel plutôt que quelque chose en dehors de lui — cette question teste si ces choix sont réellement faits ou laissés par défaut. Elle compte parce que dans la santé numérique le verrouillage le plus lourd de conséquences concerne le dossier clinique et ses données, où un stockage propriétaire sans sortie réaliste peut piéger tout un système pendant une décennie et dicter ce que chaque service en aval peut faire. Le tiraillement est vitesse contre optionnalité : acheter est plus rapide et souvent moins cher aujourd'hui, surtout pour une équipe sous tension, mais chaque achat pratique sans normes ouvertes ni droits de sortie restreint discrètement les choix de demain, et le coût ne devient visible que lorsque vous essayez de partir. Rendez cela concret en listant vos capacités essentielles, en marquant chacune comme stratégique (construire/posséder) ou de commodité (acheter), et en vérifiant si les contrats derrière celles de commodité exigent réellement des normes ouvertes (HL7 FHIR, SNOMED CT) et des droits de sortie applicables. Une bonne réponse distingue les quelques capacités véritablement stratégiques des nombreuses qui sont achetées en toute sécurité, est honnête sur les points où l'organisation est déjà verrouillée sur les données cliniques, et s'engage sur des normes ouvertes et des droits de sortie dans les contrats qui comptent le plus.

6. Comment saurons-nous quand notre modèle opérationnel doit changer, et quels signaux nous le diraient — plutôt que de réorganiser par mode ou à l'arrivée d'un nouveau dirigeant ? Le sujet présente le modèle opérationnel comme un produit que vous faites évoluer sur preuve, pas un diagramme encadré sur un mur, donc cette question demande à l'équipe de définir à l'avance quelle preuve justifierait de le remodeler. Elle compte dans la santé et l'action sociale parce que la réorganisation est perturbatrice et coûteuse — elle dissout une connaissance du domaine et de la sécurité clinique durement acquise — pourtant le secteur est sujet à un bouleversement structurel conduit par des cycles de politique et de nouvelles nominations plutôt que par le fait que le modèle actuel gêne réellement. Le tiraillement est entre stabilité et adaptation : changez le modèle trop facilement et vous ne laissez jamais les équipes s'installer ou accumuler une expertise de sécurité, changez-le trop rarement et des structures figées étranglent le flux longtemps après avoir cessé de convenir au travail. Rendez cela concret en choisissant un petit ensemble de signaux à surveiller — flux de travail, délai de décision, reprises de travail, et santé des équipes — et en convenant de quel mouvement dans ceux-ci déclencherait une refonte délibérée par rapport à un ajustement mineur. Une réponse honnête s'engage sur quelques indicateurs avancés, distingue le changement mené par la preuve du théâtre de réorganisation, et est claire sur qui est responsable d'inspecter le modèle et d'agir quand les signaux disent qu'il entrave la livraison.

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

Un ICS couvrant cinq territoires a chaque trust construisant ses propres outils de prise de rendez-vous destinés aux patients. Les coûts se dupliquent, les expériences divergent, et aucun ne partage proprement les données. L'ICS reconçoit son modèle opérationnel.

Il définit trois résultats (réduire les rendez-vous manqués, réduire les admissions évitables, améliorer l'équité d'accès) et les flux de valeur qui les sous-tendent. Il met en place une petite équipe plateforme possédant quatre capacités viables les plus minces : une identité/connexion partagée, une couche d'interopérabilité basée sur FHIR, un hébergement commun avec des bases de sécurité et de sécurité clinique, et un système de conception. Chaque territoire garde une équipe alignée sur un flux mais construit désormais sur la plateforme plutôt que de partir de zéro.

Le financement passe d'appels d'offres de projet annuels à des budgets produit permanents pour chaque flux, libérés via des portes de découverte/alpha/bêta. Une carte RAPID publiée précise que les équipes territoriales décident de leur propre conception de service dans les limites de la plateforme et de la sécurité clinique, tandis que le conseil numérique de l'ICS décide des normes de plateforme. En un an, trois territoires partagent une capacité de prise de rendez-vous, la base de conception et de sécurité est cohérente, et de nouvelles fonctionnalités qui prenaient autrefois un cycle de projet sont livrées en semaines — parce que la plateforme a absorbé le gros œuvre indifférencié.

Angles sectoriels#

Un modèle opérationnel est calibré à l'organisation qu'il sert ; les mêmes couches — flux de valeur, capacités, équipes, gouvernance, plateforme, fournisseurs — sont dessinées très différemment par une startup, une grande entreprise, et un organisme public.

Startup#

Dans une petite entreprise de santé numérique, le modèle opérationnel est surtout implicite et c'est très bien ainsi : une ou deux équipes alignées sur un flux, un fondateur détenant la plupart des droits de décision, et pas d'équipe plateforme car il n'y a encore rien à mettre en plateforme. La discipline consiste à rendre explicites tôt les quelques vraies décisions — construire ou acheter pour le stockage des données cliniques, quelles normes ouvertes adopter — afin que le raccourci d'aujourd'hui ne devienne pas le verrouillage de demain. Le maintien en condition et le changement sont entre les mêmes mains, donc le risque est que garder les lumières allumées pour les premiers clients affame la feuille de route ; une répartition simple et honnête du temps d'ingénierie est l'équivalent léger d'un budget de maintien protégé. Les fournisseurs sont choisis pour la vitesse, mais une startup devrait quand même refuser le verrouillage sur les données cliniques essentielles, car ses futurs acheteurs du NHS exigeront des droits de sortie.

Petite entreprise#

Un petit prestataire établi — un cabinet de médecine générale, une pharmacie communautaire, un établissement de soins ou un prestataire de soins à domicile, une clinique à site unique, ou un petit fournisseur de technologie de santé passé le stade de pré-revenu — a de vrais patients et des opérations continues mais pas d'équipe plateforme, pas de capacité numérique ou informatique dédiée, et peu de marge en trésorerie ou en personnel. Ici, le modèle opérationnel est largement un ensemble de capacités achetées assemblées entre elles, donc les choix décisifs sont ceux des fournisseurs : insister sur des normes ouvertes et des droits de sortie dans les systèmes cliniques que vous vous procurez, car vous portez les mêmes devoirs d'interopérabilité et de sécurité clinique qu'un grand trust sans son pouvoir d'achat ni son expertise interne. Le maintien en condition et le changement retombent sur la même poignée de personnes qui livrent aussi des soins, donc la discipline honnête consiste à protéger un peu de temps pour garder les systèmes sûrs et à jour plutôt que de seulement éteindre des incendies. Les droits de décision sont simples — généralement un partenaire ou un propriétaire-gérant décide — mais cela rend facile de reporter les décisions numériques indéfiniment, donc la valeur consiste à nommer les quelques-unes qui comptent (quel dossier clinique, quelle plateforme régionale partagée rejoindre) et à les prendre délibérément. Là où un ICS ou un organisme national offre une identité, une interopérabilité ou une plateforme de conception partagée, le meilleur choix de la petite entreprise est souvent de construire dessus plutôt que de réinventer, empruntant la capacité qu'elle ne peut pas doter elle-même.

Grande entreprise#

Un trust NHS ou un ICS est l'endroit où la forme plateforme-plus-fédération gagne sa place : des organisations souveraines qui doivent ressembler à un seul service pour un patient. Les problèmes difficiles sont autant politiques que techniques — déplacer l'argent d'appels d'offres de projet limités dans le temps vers des budgets produit permanents, et publier une carte RACI/RAPID afin que les équipes territoriales arrêtent d'escalader des décisions qu'elles possèdent. Une grande entreprise de technologie de santé ou pharmaceutique a la puissance d'ingénierie de plateforme mais risque de surconstruire une grande plateforme interne qui devient son propre goulot d'étranglement ; le test de la plateforme viable la plus mince — deux équipes ou plus ont manifestement besoin de la même chose — est le frein. À cette échelle, les droits de décision et le flux de financement sont le modèle opérationnel ; la technologie n'est généralement pas la contrainte.

Gouvernement#

Un organisme public national ou local conçoit des modèles opérationnels que d'autres organisations doivent habiter, donc ses choix sur les normes et les plateformes sont effectivement une infrastructure nationale. NHS England ou le DHSC fournissant une couche d'identité partagée, une colonne vertébrale d'interopérabilité, ou un système de conception est le schéma de plateforme appliqué à l'échelle de la population, et ses contrôles de dépenses et portes d'assurance échelonnées sont la façon dont l'argent public est tenu de rendre des comptes. Le mode de défaillance est un modèle centralisé qui devient un goulot d'étranglement distant, mandatant une seule solution pour chaque contexte local ; le correctif consiste à mettre en plateforme les capacités véritablement communes et à fédérer le reste vers les trusts et les autorités locales. La responsabilité envers le Parlement signifie aussi que construire/acheter et la gestion des fournisseurs sont des questions de registre public, donc les normes ouvertes et les droits de sortie ne sont pas simplement prudents mais attendus.

Modes de défaillance courants#

• Automatiser l'organigramme. Concevoir les équipes autour des départements existants plutôt que des flux de valeur, si bien que le TOM enracine les silos. Antidote : concevoir à partir des résultats et des flux de valeur vers le bas.
• La plateforme qui devient un goulot d'étranglement. Une équipe plateforme centrale surdimensionnée derrière laquelle chaque demande doit patienter. Antidote : plateforme viable la plus mince, traitée comme un produit avec des accords de niveau de service.
• Financement de projet pour du travail produit. L'argent qui expire force une rotation de dissolution-reconstruction. Antidote : financement produit persistant avec des portes échelonnées.
• Maintien en condition affamé pour nourrir le changement. Sous-financer les opérations de service en production jusqu'à ce que les systèmes cliniques se dégradent. Antidote : financer explicitement le maintien en condition et le changement, et protéger le budget de maintien.
• Décisions non possédées. Personne ne sait qui décide, donc tout escalade. Antidote : un RACI/RAPID publié.
• Verrouillage par défaut. Données cliniques essentielles piégées dans un système fournisseur propriétaire sans sortie. Antidote : normes ouvertes et droits de sortie dans chaque contrat stratégique.

Modèle de maturité#

Liste de contrôle#

• Le modèle opérationnel est conçu à partir des résultats et des flux de valeur, pas de la hiérarchie existante.
• Les capacités partagées sont fournies comme une plateforme viable la plus mince, les équipes de flux construisant dessus.
• Les équipes produit sont financées de façon persistante et alignées sur les flux de valeur.
• Le contrôle des dépenses est échelonné (portes découverte/alpha/bêta/production) et proportionné au risque et à la valeur.
• Les droits de décision sont documentés (RACI ou RAPID) et publiés.
• Le maintien en condition et le changement sont financés explicitement, avec le budget de maintien protégé.
• Les types d'équipe (alignée sur un flux, plateforme, habilitante, sous-système complexe) sont compris et utilisés.
• Construire/acheter est un choix délibéré par capacité ; les données cliniques essentielles évitent le verrouillage.
• Les contrats exigent des normes ouvertes (par exemple HL7 FHIR, SNOMED CT) et des droits de sortie.

Sources clés#

• Matthew Skelton et Manuel Pais — Team Topologies (équipes alignées sur un flux, plateforme, habilitantes, sous-système complexe ; plateforme viable la plus mince).
• GOV.UK Service Manual — contrôles de dépenses et assurance échelonnée (découverte/alpha/bêta/production) ; Government Digital Service.
• Manuel de service numérique du NHS — NHS service standard (service-manual.nhs.uk).
• AXELOS — Management of Portfolios (MoP) et Managing Successful Programmes (MSP) pour la gouvernance de portefeuille et de programme.
• Bain & Company — cadre de droits de décision RAPID ; et le modèle de matrice de responsabilité RACI.
• John Doerr — Measure What Matters (OKR) pour la définition des résultats.

Références#

1. Operating model — Wikipédia — https://en.wikipedia.org/wiki/Operating_model
2. Value stream — Wikipédia — https://en.wikipedia.org/wiki/Value_stream
3. Objectives and key results (OKRs) — Wikipédia — https://en.wikipedia.org/wiki/Objectives_and_key_results
4. Responsibility assignment matrix (RACI) — Wikipédia — https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
5. Vendor lock-in — Wikipédia — https://en.wikipedia.org/wiki/Vendor_lock-in
6. Government Digital Service — Wikipédia — https://en.wikipedia.org/wiki/Government_Digital_Service
7. Fast Healthcare Interoperability Resources (HL7 FHIR) — Wikipédia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
8. SNOMED CT — Wikipédia — https://en.wikipedia.org/wiki/SNOMED_CT
9. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton & Manuel Pais, IT Revolution — https://teamtopologies.com/book
10. Spend controls and staged assurance (discovery/alpha/beta/live) — GOV.UK Service Manual, Government Digital Service — https://www.gov.uk/service-manual/agile-delivery
11. NHS service standard — NHS digital service manual, NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard
12. Managing Successful Programmes (MSP) et Management of Portfolios (MoP) — AXELOS/PeopleCert — https://www.axelos.com/
13. Measure What Matters (OKRs) — John Doerr — https://www.whatmatters.com/the-book