Sujet 4.1 — Plateformes et services partagés

Dans la santé et l'action sociale, une plateforme partagée n'est pas une commodité d'économie de coûts mais une façon de rendre la sécurité, l'équité, et la confiance reproductibles — afin que chaque équipe en hérite au lieu de les réinventer, souvent mal.

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

Lorsque vous exploitez la livraison numérique à travers un système de santé et d'action sociale, vous remarquez rapidement les mêmes capacités reconstruites encore et encore. Chaque service veut authentifier un patient, consulter un dossier démographique, envoyer une notification, enregistrer une piste d'audit, ou vérifier le rôle d'un clinicien. Laissée seule, chaque équipe construit sa propre version. Vous vous retrouvez avec une douzaine d'écrans de connexion, une douzaine de façons de gérer l'identité d'un patient, une douzaine de journaux d'audit de qualité variable — et une douzaine d'endroits où un défaut de sécurité peut se cacher.

Cette duplication est coûteuse, mais le problème plus profond est qu'elle est dangereuse et inéquitable. Dans la santé et l'action sociale, la plomberie porte le risque clinique. Si la logique de correspondance de patient d'une équipe est plus faible que celle d'une autre, un patient peut recevoir le mauvais dossier. Si l'accessibilité d'un service est plus pauvre, certaines personnes sont discrètement exclues. Si les pistes d'audit diffèrent, une enquête de gouvernance de l'information stagne. Une plateforme partagée vous permet de construire une capacité une fois, selon une norme élevée, avec le travail de sécurité clinique et d'accessibilité fait correctement, puis de laisser de nombreuses équipes hériter de cette norme plutôt que de chacune parier sur le fait de bien faire seule.

Les plateformes façonnent aussi le rythme de tout le système. Une bonne plateforme signifie qu'un nouveau service peut atteindre des patients en quelques semaines plutôt qu'en années, car les parties difficiles et génériques existent déjà. Une plateforme mauvaise ou absente signifie que chaque équipe porte le poids complet de l'infrastructure, et la livraison ralentit à la vitesse de l'équipe la moins dotée en ressources. Dans un secteur sous pression financière et de main-d'œuvre soutenue, où les mêmes capacités nationales et locales sont nécessaires à des centaines d'organisations, bien faire les plateformes est l'une des décisions à plus fort levier que vous prendrez. Ce sujet porte sur comment les construire et les exploiter bien — comme des produits avec de vrais utilisateurs, pas comme une infrastructure mandatée que personne n'aime.

Concepts fondamentaux#

Une plateforme, dans ce contexte, est un ensemble de capacités sur lesquelles d'autres équipes construisent plutôt que de les construire elles-mêmes. Le cadrage moderne le plus utile est qu'une plateforme est un produit avec des utilisateurs internes. Ses clients sont vos propres développeurs, équipes de livraison, et organisations partenaires, et son succès est mesuré de la même façon que celui de tout produit : par l'adoption, par l'expérience des personnes qui l'utilisent, et par les résultats qu'elle permet.

Plusieurs idées connexes se situent en dessous de cela. Les services partagés sont le schéma organisationnel plus ancien consistant à fournir une capacité une fois pour de nombreuses parties d'une organisation plutôt que de la dupliquer dans chacune. L'infrastructure publique numérique étend cela au niveau d'une société entière — les blocs de construction partagés, réutilisables, et interopérables (identité, paiements, échange de données) sur lesquels les services publics et privés sont construits. « Le gouvernement comme plateforme », une phrase inventée par Tim O'Reilly et reprise par les équipes de gouvernement numérique du monde entier, applique la même logique à l'État : le gouvernement fournit des composants communs, et les départements composent des services à partir de ceux-ci plutôt que chacun construisant la pile complète.

Techniquement, les plateformes exposent souvent leurs capacités via une interface de programmation d'application (API) — un contrat défini qui permet à un système d'utiliser la capacité d'un autre sans connaître ses internes. Elles s'appuient fréquemment sur des modèles de cloud plateforme en tant que service (PaaS), et les plateformes nationales partagées reposent typiquement sur la multi-location (multitenancy), où une seule instance sert de nombreuses organisations tout en gardant leurs données et configuration séparées.

Trois concepts déterminent si une plateforme aide ou nuit. Le premier est la charge cognitive : une bonne plateforme réduit la quantité qu'une équipe de livraison doit garder en tête, afin que l'équipe puisse se concentrer sur le problème clinique ou de soin qu'elle existe pour résoudre. Le deuxième est la « route pavée » ou « chemin doré » : une façon par défaut, bien soutenue, et à opinion de faire une tâche commune qui est plus facile à suivre qu'à éviter, offerte via le libre-service plutôt que le gatekeeping. Le troisième est l'évitement de la dépendance envers un fournisseur (vendor lock-in), ce qui est pourquoi les plateformes devraient être construites sur des normes ouvertes afin que les organisations puissent se déplacer entre fournisseurs sans coûts de changement prohibitifs.

Dans la santé spécifiquement, les services partagés nationaux font déjà partie du paysage. Des programmes historiques tels que NHS Connecting for Health ont établi le NHS Spine, un ensemble de services nationaux portant des données centrales telles que le Personal Demographics Service. Les équivalents modernes incluent les API nationales, NHS login pour l'authentification citoyenne, et NHS Notify pour la messagerie — des capacités offertes afin que les services individuels n'aient pas besoin de les reconstruire. Là où une plateforme fournit une façon commune de prouver qui est quelqu'un, elle expose souvent l'authentification unique afin qu'un clinicien s'authentifie une fois plutôt que de manière répétée. Ce sujet concerne comment construire et exploiter de telles plateformes ; les détails de qui vous êtes et ce que vous pouvez faire appartiennent au Sujet 4.2 — Gestion des identités et des accès, et les normes qui permettent aux systèmes d'échanger des données appartiennent au Sujet 4.3 — Interopérabilité et normes de données.

Bonnes pratiques#

1. Traitez la plateforme comme un produit, pas un projet. Une plateforme a une feuille de route, un chef de produit, un financement continu, et des utilisateurs dont vous mesurez la satisfaction — pas une date de fin et une remise. Les projets se terminent et se dégradent ; les plateformes doivent être exploitées indéfiniment car les équipes finissent par en dépendre. Financez et dotez en personnel en conséquence, et voyez le Sujet 5.0 — Travail piloté par le produit pour la discipline opérationnelle que cela implique.

2. Commencez par la plateforme viable la plus mince. Construisez le plus petit ensemble de capacités partagées qui soulage véritablement les équipes, et ajoutez-en plus seulement lorsque la vraie demande et la vraie douleur le justifient. Cette idée de « plateforme viable la plus mince », introduite au Sujet 1.1 — Le modèle opérationnel, garde contre l'échec le plus courant : une plateforme centrale ambitieuse qui essaie de tout faire, arrive tard, et ne convient à personne. Laissez la plateforme croître à partir de preuves d'usage, pas d'aspiration architecturale.

3. Rendez la route pavée la route facile. Une plateforme gagne l'adoption en rendant le chemin soutenu plus rapide et plus simple que construire le vôtre — à travers l'intégration en libre-service, une documentation claire, des bacs à sable, et des paramètres par défaut sensés avec sécurité clinique et accessibilité intégrées. Si utiliser la plateforme est plus lent ou plus douloureux que la contourner, les équipes la contourneront, et vous aurez dépensé de l'argent pour créer un goulot d'étranglement. Concevez pour la première heure du développeur et son pire jour.

4. Mesurez le succès par l'adoption et l'expérience utilisateur, pas par l'existence. Les bonnes métriques sont combien d'équipes utilisent la plateforme volontairement, combien de temps prend l'intégration, à quelle fréquence la plateforme est disponible, et comment ses utilisateurs évaluent l'expérience. Les métriques de vanité telles que le nombre de services déployés ne vous disent rien sur si les équipes sont aidées. Instrumentez la plateforme, menez une recherche régulière avec les équipes qui construisent dessus, et traitez une courbe d'adoption en baisse ou stagnante comme un problème de produit à corriger, pas un problème de conformité à appliquer.

5. Construisez sur des normes ouvertes et gardez la sortie bon marché. Préférez des normes et interfaces ouvertes et largement adoptées afin que ni vous ni les équipes sur votre plateforme ne soient piégées. Documentez comment une équipe partirait, et assurez-vous qu'elle le pourrait. Paradoxalement, faciliter le départ est ce qui rend les équipes à l'aise d'arriver, et cela garde la plateforme honnête car elle doit gagner sa place plutôt que de compter sur la captivité. Cela réduit directement la dépendance fournisseur à travers le parc plus large discuté au Sujet 4.0 — Architecture technique, cloud et héritage.

6. Soyez explicite sur qui paie et qui décide. Une plateforme partagée a besoin d'un modèle de financement et d'un modèle de gouvernance convenus en amont : si elle est financée centralement, refacturée aux utilisateurs, ou hybride, et comment sa feuille de route est priorisée à travers des locataires concurrents. L'ambiguïté ici est ce qui transforme les plateformes en champs de bataille politiques. Publiez le modèle, donnez aux utilisateurs une véritable voix dans la feuille de route, et revisitez-le à mesure que la plateforme grandit.

7. Exploitez l'équipe de plateforme avec des responsabilités et frontières claires. Organisez-vous autour d'une équipe de plateforme dédiée dont le travail est d'habiliter les équipes de livraison alignées sur les flux via le libre-service, comme décrit dans les modèles Team Topologies au Sujet 7.0 — Structures d'équipe, rôles et responsabilités. Gardez l'interface entre la plateforme et les consommateurs explicite — ce que la plateforme promet, ce qu'elle ne promet pas, et comment obtenir du support — afin que la plateforme habilite plutôt qu'elle ne fasse du gatekeeping.

8. Concevez pour la multi-location, l'isolation, et la sécurité dès le début. Si de nombreuses organisations partageront une plateforme, la séparation de leurs données, configuration, et domaines de défaillance est une exigence fondamentale, pas une fonctionnalité ultérieure. Dans la santé et l'action sociale, c'est aussi une exigence de gouvernance de l'information et de sécurité clinique : l'incident d'un locataire ne doit pas exposer ou mettre en danger les patients d'un autre. Intégrez l'isolation, l'observabilité par locataire, et un dossier de sécurité clinique pour la plateforme elle-même au titre du DCB0129.

Questions à discuter avec votre équipe#

1. Quelle est la plateforme la plus mince qui soulagerait véritablement nos équipes, et qu'est-ce que nous sommes tentés de construire que nous ne devrions pas ? Il est facile de concevoir une plateforme expansive sur un tableau blanc et difficile d'en livrer une que les équipes aiment. Commencez par la douleur réelle et répétée que vos équipes de livraison ressentent aujourd'hui — la capacité que trois équipes ou plus reconstruisent chacune — et résistez à ajouter quoi que ce soit dont seule une équipe a besoin ou que personne n'a encore demandé. Demandez quelles capacités sont véritablement communes versus lesquelles semblent simplement similaires de loin mais diffèrent dans les détails qui comptent cliniquement. Considérez le coût de se tromper : une capacité partagée prématurée que les équipes doivent contourner est pire qu'aucune plateforme du tout. Convenez d'une ligne explicite entre ce que la plateforme possédera maintenant et ce qu'elle reportera délibérément. Revisitez cette ligne selon un calendrier, déplaçant des éléments à travers seulement quand la demande et la douleur sont démontrées. La discipline consiste à dire non à de bonnes idées qui ne gagnent pas encore leur place.

2. Comment financerons-nous la plateforme et déciderons-nous de sa feuille de route lorsque les locataires sont en désaccord ? Une plateforme sert de nombreuses équipes avec des priorités concurrentes, et au moment où deux locataires importants veulent des choses incompatibles, votre gouvernance est testée. Décidez maintenant si la plateforme est financée centralement, refacturée aux utilisateurs, ou hybride, et soyez honnête sur les incitations que chaque modèle crée : la refacturation peut supprimer l'adoption, tandis que le financement central peut détacher la plateforme du besoin utilisateur. Décidez qui détient la feuille de route, comment les locataires l'influencent, et comment vous arbitrez entre le besoin urgent d'une grande organisation et le besoin de base d'une petite. Considérez l'équité explicitement, car un modèle de refacturation peut exclure les organisations plus petites ou plus pauvres des capacités de sécurité partagées mêmes dont elles ont le plus besoin. Convenez de comment vous gérerez un locataire qui veut financer une fonctionnalité que les autres ne veulent pas. Écrivez le modèle et publiez-le, afin que les décisions ressemblent à de la gouvernance plutôt qu'au favoritisme. Puis engagez-vous à le revisiter à mesure que la plateforme et sa base d'utilisateurs grandissent.

3. Comment saurons-nous si la plateforme est aimée plutôt que simplement mandatée, et que ferons-nous si ce n'est pas le cas ? Une plateforme peut être techniquement solide, officiellement requise, et discrètement détestée — et une plateforme mandatée mais non aimée accumule des solutions de contournement, des systèmes fantômes, et du ressentiment. Décidez en amont quels signaux vous disent la vérité : adoption volontaire là où les équipes ont un choix, temps jusqu'au premier succès pour une nouvelle équipe, disponibilité et historique d'incidents, et retour direct des développeurs qui l'utilisent. Parlez de comment vous rassemblerez un retour honnête quand vous détenez aussi le pouvoir sur vos utilisateurs, puisque les gens sont réticents à critiquer une plateforme qu'ils sont obligés d'utiliser. Convenez de à quoi ressemble une courbe d'adoption saine et quel seuil déclencherait une refonte sérieuse. Décidez si vous seriez jamais disposé à retirer ou remplacer la plateforme si la preuve l'exigeait. Être disposé à entendre que votre plateforme ne fonctionne pas est ce qui la maintient fonctionnelle. L'alternative est de découvrir la vérité seulement quand un service majeur vous contourne.

4. Comment garderons-nous la sortie bon marché, et une équipe sur notre plateforme pourrait-elle réellement partir si elle en avait besoin ? Il est facile de revendiquer que vous êtes construit sur des normes ouvertes et tout autre chose de prouver qu'une équipe pourrait partir sans une réécriture prohibitive. Parlez honnêtement de où la dépendance s'infiltre — une interface propriétaire, un format de données non documenté, une dépendance nationale sans alternative — et si le coût de partir augmente discrètement dans le temps. Décidez qui est responsable de documenter et tester périodiquement une voie de sortie, plutôt que de supposer qu'une existe. Considérez que dans la santé et l'action sociale, le risque de dépendance se compose : une plateforme nationale construite sur la captivité peut piéger tout un système pendant une génération, et les équipes les moins capables d'absorber les coûts de changement sont habituellement les plus petits prestataires. Une réponse honnête nomme les dépendances spécifiques que vous auriez du mal à démêler, décrit une véritable sortie pour au moins un locataire réel, et traite la portabilité comme une fonctionnalité que vous maintenez plutôt qu'un slogan que vous répétez. Rappelez-vous que faciliter le départ est souvent ce qui rend les équipes à l'aise d'arriver.

5. La plateforme porte-t-elle son propre dossier de sécurité clinique, et comment empêchons-nous l'échec d'un locataire de nuire aux patients d'un autre ? Lorsque de nombreuses organisations partagent une plateforme, sa plomberie porte le risque clinique au nom de chaque service construit dessus, donc un défaut dans la correspondance de patient ou une fuite entre locataires n'est pas le problème d'une équipe mais de tous. Décidez si la plateforme a son propre dossier de sécurité DCB0129 sur lequel les équipes consommatrices peuvent véritablement compter, ou si chaque service réévalue silencieusement le même risque partagé. Discutez de comment vous isolez les données, la configuration, et les domaines de défaillance des locataires, et comment vous sauriez si cette isolation était violée — l'observabilité par locataire est la différence entre contenir un incident et le découvrir tard. Considérez aussi les conséquences de gouvernance de l'information : une enquête sur un locataire ne doit pas exiger d'exposer les dossiers d'un autre. Une réponse honnête peut pointer vers un dossier de sécurité maintenu, une frontière d'isolation testée, et un compte clair de ce que la plateforme promet sur la sécurité versus ce qui reste la responsabilité de chaque service. Traiter la sécurité et l'isolation comme fondamentales, pas comme des fonctionnalités ultérieures, est ce qui permet aux équipes d'hériter de l'assurance plutôt que de parier dessus.

6. Où se situe la ligne entre l'équipe de plateforme et les équipes qu'elle sert, et comment empêchons-nous la plateforme de devenir un goulot d'étranglement ? Une plateforme partagée peut accélérer chaque équipe ou ralentir toutes à la vitesse d'une file d'attente centrale, et la différence réside dans à quel point vous avez tracé nettement l'interface entre la plateforme et les consommateurs. Décidez ce que la plateforme possède et promet, ce qu'elle ne fait explicitement pas, et comment une équipe obtient du support sans attendre un ticket pour du travail routinier. Parlez du libre-service comme défaut : si l'intégration, le provisionnement, ou un changement commun nécessitent tous que l'équipe de plateforme agisse à la main, vous avez construit une porte plutôt qu'une route pavée. Considérez le marché de charge cognitive au cœur d'une bonne plateforme — elle devrait réduire ce qu'une équipe de livraison doit garder en tête afin qu'elle puisse se concentrer sur le problème clinique, pas ajouter une nouvelle couche à négocier. Une réponse honnête nomme les tâches qui canalisent encore à travers l'équipe de plateforme comme un goulot d'étranglement, fixe une direction pour les rendre en libre-service, et est franche sur où la plateforme habilite versus où elle fait du gatekeeping.

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

Un Integrated Care System (ICS) couvrant plusieurs trusts du NHS, des prestataires communautaires, et le service d'action sociale pour adultes d'un conseil de comté frappe constamment le même mur. Chaque nouveau service numérique — un service virtuel, un formulaire d'auto-orientation pour la physiothérapie communautaire, un outil de supervision de maison de retraite — passe ses trois premiers mois à reconstruire les mêmes fondations : prouver qui est le patient, vérifier le rôle du professionnel, envoyer des rappels SMS, et écrire une piste d'audit. La correspondance de patient de l'équipe de service virtuel s'avère plus faible que celle de l'équipe de physiothérapie, et un quasi-incident se produit lorsqu'un rappel est envoyé à la mauvaise personne. La direction numérique de l'ICS reconnaît le schéma : ils paient plusieurs fois pour des capacités qui devraient exister une fois, et la variation est un risque de sécurité.

Plutôt que de commander une grande plateforme ICS, ils commencent minces. Ils mettent en place un seul service partagé qui fait une chose bien : il enveloppe NHS login et le Personal Demographics Service national derrière une API propre et documentée avec un bac à sable, afin que toute équipe puisse vérifier l'identité d'un citoyen et récupérer un dossier démographique confirmé via un chemin soutenu unique. Une petite équipe de plateforme de cinq personnes le traite comme un produit. Elle publie un guide de route pavée, offre une intégration en libre-service, et fixe un objectif qu'une nouvelle équipe devrait faire son premier appel réussi en un jour. Fait crucial, ils ne le mandatent pas. Ils en font l'option la plus facile et laissent l'équipe de service virtuel être le premier adopteur volontaire.

Le modèle de financement est convenu ouvertement : l'ICS finance centralement le cœur de la plateforme pour ses deux premières années afin que l'adoption ne soit pas supprimée par la refacturation, avec une révision à dix-huit mois. Un groupe transprestataire, incluant le conseil, détient la feuille de route et se réunit mensuellement. Lorsque l'équipe de physiothérapie demande ensuite une capacité de notification, l'équipe de plateforme ajoute une fine enveloppe autour de NHS Notify plutôt que de construire la messagerie à partir de zéro — construire une fois, utiliser plusieurs fois. En un an, six équipes ont adopté le service d'identité volontairement, l'intégration est passée de mois à jours, et l'équipe de plateforme publie ouvertement ses chiffres de disponibilité et d'adoption. Lorsque le système sur mesure d'un trust contourne la plateforme, l'équipe le traite comme de la recherche plutôt que de la défiance, apprend la friction qui a motivé la décision, et la corrige. La plateforme grandit car les équipes la choisissent, et l'ICS hérite d'une façon unique, bien testée, et accessible de faire les choses risquées et communes.

Angles sectoriels#

Startup#

Une startup de health-tech construit rarement des plateformes pour d'autres ; elle construit sur elles. Votre levier vient de la consommation de plateformes nationales et cloud — NHS login, API nationales, services gérés d'un fournisseur cloud — afin que votre petite équipe dépense son énergie sur le problème clinique, pas à réinventer l'identité ou la messagerie. Surveillez quand même la dépendance : choisissez des normes ouvertes et gardez vos données portables, car la capacité que vous louez à bas prix aujourd'hui peut devenir la dépendance qui vous contraint demain. En interne, gardez votre propre « plateforme » mince jusqu'au point de quasi-invisibilité ; une équipe de deux personnes n'a pas besoin d'une abstraction de chemin doré, elle a besoin de livrer. La discipline consiste à savoir quand vous avez assez grandi pour qu'une capacité interne partagée vaille la peine d'être extraite.

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 — est presque toujours un consommateur de plateforme avec peu ou aucune capacité numérique propre, donc les plateformes dont il dépend fixent effectivement son plancher de sécurité et d'équité. Votre tâche pratique est de choisir des services partagés soutenus plutôt que des constructions sur mesure que vous ne pouvez pas doter en personnel ou maintenir, favorisant des capacités nationales telles que NHS login, la consultation démographique, et NHS Notify qui portent déjà un travail d'accessibilité et de sécurité clinique que vous ne pourriez jamais financer seul. Insistez pour une véritable intégration en libre-service et une documentation claire, car vous n'avez aucune équipe de plateforme vers laquelle escalader et ne pouvez pas vous permettre un long projet d'intégration. Surveillez le modèle de financement de près : une plateforme de refacturation peut exclure un petit prestataire des capacités de sécurité mêmes dont il a le plus besoin, donc poussez pour un accès équitable et soulevez-le dans toute gouvernance de feuille de route que vous pouvez atteindre. Gardez aussi un œil sur la sortie, car une dépendance de fournisseur propriétaire est la plus difficile à échapper quand vous n'avez aucun personnel technique interne pour vous migrer. Le gain est qu'une bonne plateforme partagée vous permet d'hériter de normes que vous ne pourriez pas construire, satisfaisant les mêmes obligations que les grandes organisations sans leurs ressources.

Entreprise#

Un grand trust ou organisme national a l'échelle pour justifier de véritables plateformes et la bureaucratie pour les ruiner. Le risque est une équipe de plateforme centrale qui devient une tour d'ivoire — architecturalement élégante, lente à répondre, et détachée des équipes de livraison qu'elle est censée servir. Contrez cela en finançant les plateformes comme des produits de longue durée avec leurs propres feuilles de route et recherche utilisateur, et en les mesurant sur l'adoption et l'expérience développeur plutôt que sur la conformité au mandat. La multi-location, l'isolation, et un dossier de sécurité clinique pour la plateforme elle-même deviennent essentiels à cette échelle. Le prix est énorme : une capacité construite une fois selon une norme élevée et héritée par des dizaines de services, élevant le plancher pour toute l'organisation.

Gouvernement#

Au niveau national et systémique, le cadrage est l'infrastructure publique numérique et le gouvernement comme plateforme : construire des composants communs — identité, notifications, consultation démographique, échange de données — que des centaines d'organisations composent en services. Les enjeux pour l'ouverture sont les plus élevés ici, car une plateforme nationale construite sur la dépendance propriétaire peut piéger tout un système de santé pendant une génération. La gouvernance et le financement doivent être élaborés en public, avec une véritable influence pour les organisations plus petites et plus pauvres que les plateformes partagées existent en partie pour protéger. La tentation de mandater est la plus forte et la plus dangereuse à ce niveau ; une plateforme nationale requise mais non aimée engendre des systèmes fantômes à travers le pays. Gagnez l'adoption à travers la qualité et le support, et traitez chaque solution de contournement comme un signal à améliorer.

Modes d'échec courants#

• Le goulot d'étranglement. Chaque équipe doit attendre l'équipe de plateforme centrale pour faire quoi que ce soit, donc la plateforme ralentit la livraison au lieu de l'accélérer. Le remède est le libre-service : les équipes devraient pouvoir s'intégrer et agir sans ticket.
• La tour d'ivoire. La plateforme est conçue par des personnes distantes de la livraison, est techniquement admirable, et ne convient aux besoins réels d'aucune équipe. Le remède est d'exploiter la plateforme comme un produit avec une recherche utilisateur continue.
• Mandatée mais non aimée. La plateforme est requise par politique mais contournée en pratique, accumulant des systèmes fantômes et du ressentiment. Le remède est de gagner l'adoption à travers la qualité et d'écouter quand les équipes vous contournent.
• La plateforme qui fait tout. Un périmètre trop ambitieux signifie que la plateforme arrive tard, fait trop, et ne fait bien rien de tout cela. Le remède est la plateforme viable la plus mince, grandie à partir de preuves de demande.
• Dépendance furtive. La plateforme lie discrètement les équipes à un fournisseur ou une interface propriétaire, et le coût de partir devient prohibitif. Le remède est des normes ouvertes et une voie de sortie documentée et testée.
• Ambiguïté de financement. Personne n'a convenu qui paie ou qui décide, donc la plateforme s'affame ou devient un champ de bataille politique. Le remède est un modèle explicite et publié de financement et de gouvernance.
• Sécurité en réflexion après coup. La plateforme n'a pas son propre dossier de sécurité clinique, donc chaque service consommateur hérite d'un risque non évalué. Le remède est de traiter le dossier de sécurité DCB0129 de la plateforme comme fondamental.

Modèle de maturité#

Liste de contrôle#

• La plateforme a un chef de produit nommé, une feuille de route, et un financement continu (pas de projet).
• Vous avez commencé par la plateforme viable la plus mince et pouvez nommer ce que vous avez délibérément reporté.
• Le chemin soutenu est véritablement plus rapide et plus facile que les équipes construisant le leur.
• Les nouvelles équipes peuvent s'intégrer via le libre-service, avec un bac à sable et une documentation claire.
• Vous mesurez l'adoption, le temps jusqu'au premier succès, la disponibilité, et l'expérience développeur.
• Le modèle de financement (central, refacturation, ou hybride) est convenu et publié.
• La gouvernance de feuille de route donne aux locataires, y compris les organisations plus petites, une véritable voix.
• La plateforme est construite sur des normes ouvertes et une voie de sortie documentée existe.
• L'isolation multi-locataire des données et des défaillances est conçue en amont, pas ajoutée après coup.
• La plateforme a son propre dossier de sécurité clinique (DCB0129) sur lequel les équipes consommatrices peuvent compter.
• Vous traitez les équipes qui contournent la plateforme comme de la recherche, pas de la défiance.

Sources clés#

• GOV.UK Service Manual and the Government Digital Service writing on government as a platform and common components.
• Matthew Skelton and Manuel Pais, Team Topologies — platform teams, thinnest viable platform, and cognitive load.
• NHS England developer and API guidance (NHS login, NHS Notify, national APIs, and the Spine services).
• DCB0129 and DCB0160 clinical risk management standards for health IT systems.
• The World Bank and United Nations writing on digital public infrastructure and reusable public building blocks.
• Tim O'Reilly, "Government as a Platform", in Open Government (O'Reilly Media).

Références#

1. Digital public infrastructure — Wikipédia — https://en.wikipedia.org/wiki/Digital_public_infrastructure
2. Shared services — Wikipédia — https://en.wikipedia.org/wiki/Shared_services
3. API (application programming interface) — Wikipédia — https://en.wikipedia.org/wiki/API
4. Platform as a service — Wikipédia — https://en.wikipedia.org/wiki/Platform_as_a_service
5. Multitenancy — Wikipédia — https://en.wikipedia.org/wiki/Multitenancy
6. Cognitive load — Wikipédia — https://en.wikipedia.org/wiki/Cognitive_load
7. Vendor lock-in — Wikipédia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Open standard — Wikipédia — https://en.wikipedia.org/wiki/Open_standard
9. NHS Connecting for Health (including the NHS Spine and Personal Demographics Service) — Wikipédia — https://en.wikipedia.org/wiki/NHS_Connecting_for_Health
10. Single sign-on — Wikipédia — https://en.wikipedia.org/wiki/Single_sign-on
11. Team Topologies: Organizing Business and Technology Teams for Fast Flow — Matthew Skelton and Manuel Pais (IT Revolution Press) — https://teamtopologies.com/book
12. Government as a Platform — Tim O'Reilly, in Open Government (O'Reilly Media) — https://www.oreilly.com/library/view/open-government/9781449381936/ch02.html
13. GOV.UK Service Manual — Government Digital Service — https://www.gov.uk/service-manual
14. NHS login and NHS England developer/API guidance — NHS England — https://digital.nhs.uk/services/nhs-login
15. Clinical risk management: its application in the manufacture of health IT systems (DCB0129) — NHS England — https://digital.nhs.uk/services/clinical-safety/documentation