Sujet 4.0 — Architecture technique, cloud et héritage

Dans la santé et l'action sociale, l'architecture technique est une décision de sécurité clinique, de sécurité, et d'argent public prise des années à l'avance : les plateformes que vous mettez en place et l'héritage que vous laissez en place déterminent discrètement si les soins peuvent être sûrs, connectés, et abordables longtemps après que les personnes qui les ont choisis soient passées à autre chose.

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

L'architecture est l'ensemble des choix structurels de longue durée sous vos services numériques : ce qui fonctionne où, comment les composants se connectent, ce que vous construisez versus achetez, et ce que vous gardez vivant du passé. Ces choix sont rarement visibles pour les patients ou cliniciens, et rarement excitants pour les conseils d'administration. Pourtant, ils façonnent tout ce qui se trouve par-dessus. Un parc bien architecturé vous permet d'ajouter un nouveau service rapidement, partager des données en sécurité, et récupérer vite quand quelque chose se casse. Un parc mal architecturé rend chaque changement lent, chaque intégration fragile, et chaque incident pire.

Dans la santé et l'action sociale, les enjeux sont élevés car les systèmes ont des conséquences. Lorsqu'un système d'administration des patients vieillissant tombe, les ambulances se déroutent et les cliniques s'annulent. Lorsqu'un système d'exploitation non supporté est exploité, des dossiers confidentiels sont exposés et les services s'arrêtent — comme le NHS l'a appris en 2017 lorsque l'attaque du rançongiciel WannaCry s'est propagée à travers des machines exécutant un logiciel qui ne pouvait plus être corrigé. Cette perturbation n'était pas un assaut intelligent et ciblé ; c'était la conséquence prévisible de la dette technique accumulée dans les systèmes critiques. Les décisions d'architecture sont donc des décisions de sécurité, que quiconque les cadre ainsi ou non.

Ce sont aussi des décisions d'équité et de confiance. Les systèmes hérités qui ne peuvent pas partager de données laissent les patients les plus complexes — ceux touchant de nombreux services — avec les dossiers les plus fragmentés. Les plateformes fermées qui vous enferment dans un seul fournisseur drainent de l'argent qui pourrait financer des soins. Et le public attend raisonnablement que le NHS fonctionne sur une technologie moderne, sécurisée, et bien maintenue ; l'écart entre cette attente et le parc réel est en soi un risque pour la confiance.

Enfin, c'est là où une grande quantité d'argent public est engagée pour très longtemps. La partie la plus coûteuse d'un système est rarement son achat ; c'est la décennie d'hébergement, de licences, de maintenance, et de remplacement éventuel qui suit. Les dirigeants qui traitent l'architecture comme « quelque chose que l'équipe technique gère » délèguent certains des engagements financiers les plus grands et les plus durables que l'organisation prend. Ce sujet est écrit afin que vous puissiez tenir ces décisions responsables sans être ingénieur.

Concepts fondamentaux#

L'architecture d'entreprise est la discipline consistant à aligner les processus métier, l'information, les applications, et la technologie d'une organisation afin qu'ils soutiennent la stratégie de manière cohérente plutôt que de croître par accident. Elle prend la vue de l'organisation entière : quelles capacités vous avez besoin, quels systèmes les fournissent, et où se trouvent les lacunes et duplications. L'architecture de solution est la discipline plus étroite, au niveau du projet, consistant à concevoir comment un service spécifique sera construit et s'insérera dans le parc plus large. Les deux se situent dans l'idée plus large de l'architecture de systèmes — le modèle structurel de comment les composants, interfaces, et comportements se combinent en un tout fonctionnel. Les dirigeants n'ont pas besoin de pratiquer ces disciplines, mais ils devraient insister sur leur existence, car leur absence est comment les parcs deviennent ingérables.

L'architecture est guidée par des principes d'architecture : un petit ensemble convenu de déclarations — telles que « réutiliser avant d'acheter, acheter avant de construire » ou « construire selon des normes ouvertes » — qui rendent possibles des décisions cohérentes sans que chaque choix ne soit escaladé. Les principes sont appliqués, légèrement, par une autorité de conception : un petit groupe qui révise les décisions techniques significatives. La version saine d'une autorité de conception habilite plutôt que bloque ; elle existe pour prévenir le préjudice et la duplication évitables, pas pour ralentir les équipes ou faire du gatekeeping pour lui-même.

Le cloud computing est la livraison de l'informatique — serveurs, stockage, bases de données, réseau — comme un service à la demande via internet, plutôt que depuis du matériel que vous possédez dans votre propre bâtiment. Un cloud public est exploité par un fournisseur tiers et partagé entre de nombreux clients ; un cloud privé est dédié à une organisation ; un cloud hybride combine les deux, gardant souvent certaines charges de travail sur l'infrastructure existante tout en déplaçant d'autres. De nombreux gouvernements, y compris celui du Royaume-Uni, ont adopté une politique « cloud d'abord », signifiant que les équipes devraient considérer le cloud public avant d'autres options et justifier de ne pas l'utiliser. Parce que le cloud est facturé à la consommation plutôt qu'acheté une fois, contrôler cette dépense est devenu sa propre discipline — FinOps, la pratique de rassembler l'ingénierie et les finances afin que les équipes aient une visibilité sur, et une responsabilité pour, ce que leur usage cloud coûte réellement. Au niveau de la couche applicative, le logiciel en tant que service (SaaS) livre une application terminée via le web que le fournisseur héberge et maintient, donc vous la configurez plutôt que de l'exploiter. L'infrastructure et l'hébergement — où et comment vos systèmes fonctionnent physiquement — se situent sous tout cela, et portent de plus en plus un coût carbone qui appartient à la décision (voir Sujet 8.5 — Durabilité et zéro émission nette).

Un système hérité est un système vieillissant mais dont on dépend toujours qui est difficile à changer, exécutant souvent un logiciel non supporté pour lequel les correctifs de sécurité ne sont plus émis. L'héritage s'accumule comme de la dette technique — le coût futur des choix expédients faits dans le passé. Un peu de dette est normal et même sensé ; une dette non gérée à l'échelle devient une responsabilité de sécurité et de sûreté, car les systèmes dont la plupart des gens dépendent deviennent les systèmes que personne n'ose toucher. Gérer cela est le travail de la gestion de portefeuille d'applications : maintenir un inventaire clair de chaque application, son coût, sa condition, et sa valeur métier, afin de pouvoir rationaliser le parc — retirer, remplacer, ou consolider des systèmes — et désengager en toute sécurité plutôt que de laisser l'ancienne chose fonctionner discrètement.

Les parcs modernes sont maintenus ensemble par des interfaces de programmation d'application (API) : interfaces définies à travers lesquelles un système offre une capacité à un autre. Des API bien conçues vous permettent d'assembler des plateformes — services réutilisables sur lesquels de nombreuses équipes construisent — tout en gardant les composants faiblement couplés et remplaçables. Une discipline utile ici est la « plateforme viable la plus mince » : construisez seulement la capacité partagée qui réduit véritablement le travail des autres, et pas plus. Sous-tendant la conception sécurisée se trouve le sécurisé par conception, le principe que la sécurité est intégrée dès le début plutôt qu'ajoutée après coup. Et le cadre financier pour tout cela est le coût total de possession (TCO) : le coût de vie entier d'un système, pas son prix d'achat — le prisme à travers lequel le choix construire/acheter/configurer, et le risque de dépendance envers un fournisseur (vendor lock-in), devraient être jugés.

Bonnes pratiques#

1. Convenez d'un court ensemble de principes d'architecture et utilisez-les pour décider. Écrivez une poignée de principes clairs et mémorables — réutiliser avant d'acheter avant de construire, construire selon des normes ouvertes, cloud là où c'est sensé, sécurisé par conception, concevoir pour tout le parcours de soins — et laissez les équipes prendre la plupart des décisions elles-mêmes en les appliquant. Les principes ne fonctionnent que s'ils sont véritablement utilisés pour dire oui et non, et seulement s'ils sont assez peu nombreux pour être mémorisés. Cela se connecte directement au Sujet 1.1 — Le modèle opérationnel et au Sujet 1.2 — Stratégie numérique et feuille de route, qui fixent la direction que les principes servent.

2. Exploitez une autorité de conception qui habilite plutôt que bloque. Établissez un petit groupe senior et transdisciplinaire pour réviser les décisions techniques significatives — celles qui sont coûteuses, difficiles à inverser, affectent de nombreux services, ou portent un risque de sécurité et de sûreté. Donnez-lui une voie rapide et légère afin que les choix routiniers ne soient pas traînés à travers, et tenez-la à une norme de service : elle devrait aider les équipes à trouver une bonne réponse, pas simplement refuser. Une autorité de conception qui devient un goulot d'étranglement sera contournée, et l'architecture fantôme est pire que rien.

3. Adoptez le cloud délibérément, charge de travail par charge de travail, pas comme un slogan. Traitez le « cloud d'abord » comme un défaut à raisonner, pas une instruction de tout déplacer. Évaluez chaque charge de travail pour l'adéquation, la résidence des données, la résilience, le coût à l'échelle, et l'effort de migration, et soyez honnête que le lift-and-shift d'une application héritée non modifiée déplace souvent simplement le problème à un coût plus élevé. Pesez la dimension carbone explicitement, puisque où et comment vous hébergez affecte les émissions (voir Sujet 8.5 — Durabilité et zéro émission nette), et concevez pour la portabilité afin qu'un futur déplacement entre fournisseurs reste possible.

4. Maintenez un portefeuille d'applications vivant et gérez la dette technique comme un risque nommé. Maintenez un inventaire précis de chaque application, son propriétaire métier, son coût, sa supportabilité, et le risque qu'elle porte, et révisez-le régulièrement. Placez la dette technique et le logiciel non supporté sur le registre des risques d'entreprise avec le même sérieux que le risque clinique ou financier, car c'est ce que c'est. Ce que vous ne pouvez pas voir, vous ne pouvez pas le financer, le prioriser, ou le retirer en toute sécurité, et les parcs jamais inventoriés sont exactement ceux qui échouent sans avertissement.

5. Rationalisez le parc et désengagez en toute sécurité. Retirez activement les systèmes dupliqués, obsolètes, et en fin de vie plutôt que de les laisser traîner « juste au cas où », car chaque système en direct est une surface d'attaque, un coût de licence, et un fardeau de maintenance. Le désengagement est un projet à part entière : migrer ou archiver les données selon des règles de conservation claires, confirmer que rien ne dépend plus du système, communiquer avec les utilisateurs, et vérifier avant d'éteindre. Bien fait, la rationalisation libère de l'argent et réduit le risque ; mal fait, elle détruit des dossiers ou casse une dépendance que personne n'a documentée.

6. Préférez les normes ouvertes, les API, et les composants faiblement couplés. Concevez afin que les capacités soient exposées via des API documentées et versionnées, afin qu'un composant puisse être remplacé sans reconstruire tout autour. C'est la fondation architecturale pour l'interopérabilité discutée au Sujet 4.3 — Interopérabilité et normes de données, et c'est votre principale défense contre la dépendance. Cela coûte un peu plus en amont qu'une connexion directe et câblée en dur, et se rembourse de nombreuses fois la première fois que vous avez besoin de changer de fournisseur ou d'ajouter un service.

7. Construisez la plateforme viable la plus mince, et pas plus. Lorsque vous créez une plateforme partagée sur laquelle d'autres construiront, résistez à l'envie de la rendre exhaustive dès le premier jour. Fournissez la plus petite capacité réutilisable qui supprime véritablement du travail pour les équipes, prouvez qu'elle est utilisée, et développez-la en réponse à une véritable demande. Les plateformes surconstruites deviennent leur propre héritage — coûteuses, rigides, et ressenties négativement — tandis qu'une plateforme mince et bien exploitée gagne l'adoption et évolue avec le besoin.

8. Rendez l'architecture de sécurité et le sécurisé par conception non négociables. Amenez la pensée de sécurité dans la conception dès le premier croquis, pas comme une porte avant lancement : minimisez la surface d'attaque, appliquez le moindre privilège, segmentez les réseaux, et supposez que les composants seront sondés. Dans la santé et l'action sociale, cela est indissociable de la sécurité clinique et de la gouvernance de l'information (Sujet 1.6 — Sécurité clinique et gestion des risques ; Sujet 1.7 — Gouvernance de l'information, protection des données et cybersécurité), car une brèche est à la fois un préjudice de données et, lorsqu'elle arrête des systèmes, un événement de sécurité patient. Un logiciel non supporté et non corrigible est une décision de sécurité que vous prenez par défaut — donc prenez-la délibérément, avec des atténuations, ou pas du tout.

9. Décidez construire, acheter, ou configurer sur le coût total de possession, pas le prix affiché. Pour chaque capacité, comparez construire sur mesure, acheter un produit, et configurer une plateforme existante sur leur coût de vie entier — hébergement, licences, intégration, support, mises à niveau, et sortie éventuelle — pas le prix initial. Favorisez l'achat ou la configuration pour les besoins de commodité et réservez la construction pour la véritable différenciation, et pesez la dépendance que chaque option crée. Travaillez cela avec des collègues commerciaux (Sujet 6.3 — Achats et commercial), car le moment le moins cher pour sécuriser des interfaces ouvertes et des droits de sortie est avant de signer.

10. Traitez la dépense cloud comme une discipline partagée d'ingénierie et de finance (FinOps). Donnez aux équipes une visibilité claire sur ce que leurs services coûtent en étiquetant les ressources cloud à des propriétaires, dimensionnez correctement les instances contre l'usage réel, et éteignez les ressources inactives ou surprovisionnées plutôt que de les payer mois après mois. Rendez les équipes qui exploitent un service responsables de son coût d'exploitation, afin que les personnes les mieux placées pour réduire le gaspillage soient celles qui voient la facture. Le cloud à la consommation sans cette discipline consomme discrètement un budget qui devrait financer les soins, et la dérive est rarement remarquée jusqu'à ce qu'une facture force la question.

11. Concevez l'architecture pour le coût comme une exigence non fonctionnelle de premier ordre, pesée contre le carbone et la résilience. Traitez le coût comme vous traitez la performance, la sécurité, et la disponibilité : une propriété pour laquelle vous concevez délibérément, estimez avant de construire, et révisez à mesure que l'usage croît. Pesez-le explicitement contre le carbone (voir Sujet 8.5 — Durabilité et zéro émission nette) et contre la résilience, car les trois se déplacent souvent ensemble — mais ne poursuivez jamais la facture la plus basse au détriment de la sécurité, de la récupérabilité, ou des résultats patients. La bonne réponse est le coût le plus bas qui satisfait toujours vos obligations de sécurité clinique et de résilience, pas l'option la moins chère en isolation.

Questions à discuter avec votre équipe#

1. Lesquels de nos systèmes critiques sont non supportés ou non corrigibles aujourd'hui, et quelle est notre véritable exposition si l'un est attaqué ou échoue ? Commencez par les systèmes sans lesquels les services cliniques et opérationnels ne peuvent véritablement pas fonctionner, et établissez concrètement lesquels exécutent un logiciel qui ne reçoit plus de mises à jour de sécurité ou de support fournisseur. Demandez ce qui se passerait — aux patients, au personnel, aux données — si chacun était frappé par un rançongiciel ou s'arrêtait simplement, et combien de temps prendrait la récupération. Distinguez les systèmes sur lesquels vous avez consciemment accepté un risque, avec des atténuations en place, de ceux dont personne n'a évalué la fragilité. Considérez si cette exposition est visible sur le registre des risques d'entreprise ou enterrée dans une feuille de calcul qu'aucun conseil d'administration n'a vue. Réfléchissez à WannaCry : le préjudice ne venait pas de la sophistication mais de la dette connue et non traitée dans les systèmes critiques. Si vous ne pouvez pas répondre à cela avec des preuves, cet écart est en soi votre conclusion la plus urgente, car vous ne pouvez pas financer un risque que vous n'avez pas nommé.

2. Où sommes-nous enfermés, et que nous en coûterait-il véritablement de quitter notre plus grande plateforme ? De nombreuses organisations découvrent le véritable prix d'un système fermé seulement lorsqu'elles essaient de le changer. Passez en revue ce qu'il faudrait réellement pour quitter votre plus grande plateforme clinique ou corporative : si vous pouvez extraire vos données sous une forme utilisable et standard, quelles interfaces propriétaires devraient être démêlées, et ce que dit votre contrat sur la propriété et la sortie. Considérez si le « cloud » est discrètement devenu une dépendance d'un type différent, avec les données et l'outillage si entremêlés chez un fournisseur que partir est impraticable. Pesez cela contre l'ouverture des alternatives et toutes plateformes nationales que vous pourriez réutiliser à la place. Ce n'est pas un argument pour changer constamment de fournisseurs ; c'est comprendre votre levier avant votre prochaine négociation, et ne pas laisser la feuille de route d'un fournisseur devenir discrètement votre seule option.

3. Investissons-nous assez dans le maintien et la rationalisation de ce que nous avons déjà, ou seulement dans le nouveau et le visible ? Les nouveaux systèmes attirent le financement et l'attention ; le travail peu glamour de correction, mise à niveau, consolidation, et retrait sûr le fait rarement, ce qui est exactement comment la dette s'accumule. Demandez quelle proportion de votre budget numérique va réellement au maintien du parc existant en sécurité et à jour versus la construction de nouvelles choses, et si quelqu'un possède délibérément cet équilibre. Discutez de si le désengagement est jamais correctement doté en ressources, ou si les anciens systèmes traînent simplement parce qu'éteindre n'est le travail de personne. Considérez les applications dupliquées faisant la même chose à travers l'organisation, et ce qu'il faudrait pour les consolider. Pensez à qui, au niveau du conseil d'administration, est responsable de la santé du parc dans son ensemble plutôt que des projets individuels. Une organisation qui ne finance que le nouveau emprunte contre sa propre sécurité future, et le remboursement arrive toujours au pire moment possible.

4. Savons-nous réellement ce que notre cloud coûte, qui possède cette facture, et si la dépense est sous contrôle ? Le cloud à la consommation peut discrètement consommer un budget qui devrait financer les soins, et la dérive est rarement remarquée jusqu'à ce qu'une facture force la question. Demandez si les ressources cloud sont étiquetées aux équipes et services qui les possèdent, si quelqu'un dimensionne correctement les instances contre l'usage réel, et si les ressources inactives ou surprovisionnées sont jamais éteintes. Discutez de si les personnes qui exploitent un service voient et répondent de son coût d'exploitation, ou si la dépense cloud atterrit comme une seule ligne inexpliquée dans un budget central que personne ne peut décomposer. Considérez si le coût est traité comme une exigence non fonctionnelle de premier ordre — estimé avant de construire et révisé à mesure que l'usage croît — ou seulement découvert après coup. Soyez honnête sur la tension entre l'autonomie d'ingénierie et le contrôle financier, et sur peser le coût contre le carbone et la résilience plutôt que simplement poursuivre la facture la plus basse. Une réponse honnête nomme qui tient la discipline FinOps et montre la preuve qu'elle fonctionne, plutôt que de supposer que le cloud est moins cher parce qu'il est moderne.

5. Lorsque nous avons besoin d'une nouvelle capacité, comment décidons-nous entre la construire, l'acheter, et configurer quelque chose que nous avons déjà — et sur quelle base ? L'instinct de construire sur mesure, ou d'acheter le produit avec la meilleure démo, gagne souvent avant que quiconque n'ait comparé le coût de vie entier. Passez en revue comment vos derniers choix significatifs ont réellement été faits : si l'hébergement, les licences, l'intégration, le support, les mises à niveau, et la sortie éventuelle ont été pesés, ou seulement le prix initial. Demandez si vous réservez la construction pour la véritable différenciation et par défaut achetez ou configurez pour les besoins de commodité, ou si les constructions sur mesure prolifèrent discrètement parce qu'une équipe les préférait. Considérez qui est dans la pièce pour ces décisions — collègues commerciaux et cliniques ainsi qu'ingénieurs — et si la dépendance que chaque option crée est évaluée avant de signer plutôt que découverte plus tard. Réfléchissez à si vos principes d'architecture (« réutiliser avant d'acheter, acheter avant de construire ») lient véritablement ces choix ou sont discrètement ignorés. Une réponse honnête peut pointer vers de véritables décisions où le coût total de possession, pas le prix affiché, a changé le résultat.

6. Avons-nous la capacité d'architecture interne pour tenir nos propres décisions, ou dépendons-nous des fournisseurs que nous sommes censés tenir responsables ? L'architecture est là où les engagements les plus grands et les plus durables sont pris, pourtant de nombreuses organisations ont vidé la capacité même nécessaire pour bien les prendre, s'appuyant sur les fournisseurs dont les produits sont sous évaluation pour leur dire à quoi ressemble le bien. Demandez si vous avez une compétence crédible d'architecture d'entreprise et de solution de votre propre côté, et si votre autorité de conception est dotée en personnel pour habiliter les équipes ou simplement pour tamponner. Discutez de si les décisions significatives et difficiles à inverser sont véritablement testées contre des principes convenus, ou si elles sont effectivement déléguées à quel que soit le fournisseur le plus proche du problème. Considérez comment vous reconnaîtriez même une mauvaise recommandation architecturale si vous n'aviez aucune expertise indépendante pour la contester. Pesez le coût de construire et retenir cette capacité contre le coût bien plus grand de la dépendance et du retravail que son absence produit. Une réponse honnête distingue les décisions que vous pouvez véritablement posséder de celles que vous prenez actuellement sur la foi.

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

Le parc technique d'un trust hospitalier de soins aigus a grandi organiquement pendant deux décennies. En son cœur se trouve un système d'administration des patients fonctionnant sur un système d'exploitation que le fournisseur a cessé de supporter il y a dix-huit mois ; autour, plus de deux cents applications, nombreuses achetées par département, plusieurs faisant des travaux qui se chevauchent, et personne ne détient une liste complète. Un quasi-incident — une tentative de rançongiciel bloquée plus par chance que par conception — pousse le conseil d'administration à poser une question qu'il n'a jamais posée auparavant : qu'exploitons-nous exactement, et à quel point sommes-nous exposés ?

Le directeur de l'information numérique résiste à l'instinct de lancer un programme unique et héroïque de « tout remplacer », et fait d'abord le travail ennuyeux. Le trust construit un portefeuille d'applications vivant : chaque système, son propriétaire métier, sa supportabilité, son coût, et son risque. Le tableau est édifiant — un cinquième des applications tournent sur un logiciel non supporté, et une douzaine de capacités dupliquées déjà disponibles ailleurs — mais pour la première fois c'est visible, et les pires expositions vont directement sur le registre des risques d'entreprise où le conseil d'administration peut les voir.

À partir de cet inventaire, le trust fait des choix délibérés guidés par une poignée de principes d'architecture convenus. Le système d'administration des patients non supporté est priorisé pour remplacement, acheté comme un produit configurable avec des droits contractuels d'API ouverte et d'extraction de données afin que le trust ne soit pas à nouveau enfermé. Les charges de travail adéquates se déplacent vers le cloud public, évaluées une à la fois plutôt que par slogan, avec le carbone et la portabilité pesés aux côtés du coût. Une petite autorité de conception révise les décisions significatives et clarifie rapidement les routinières. Douze applications départementales qui se chevauchent sont consolidées en trois, et les systèmes retirés sont désengagés correctement — données migrées selon des règles de conservation claires, dépendances vérifiées, utilisateurs informés, et seulement alors éteints.

Rien de tout cela ne fait la une. Mais dix-huit mois plus tard, le trust sait ce qu'il exploite, sa dette la plus dangereuse est remboursée selon un plan financé plutôt qu'espérée disparaître, et une nouvelle intégration de dossier de soins partagé est livrée en quelques semaines car les systèmes de remplacement exposent des API ouvertes. Le quasi-incident est devenu le moment où le trust a commencé à gérer son architecture au lieu d'être géré par elle.

Angles sectoriels#

Startup#

Une startup de santé numérique a le luxe de peu d'héritage et devrait le protéger farouchement. Construisez natif cloud dès le départ, exposez des API ouvertes, et traitez le sécurisé par conception comme une fonctionnalité centrale plutôt qu'un coût ultérieur, car les acheteurs prudents du NHS scruteront de près votre architecture de sécurité et vos conditions d'extraction de données. Gardez votre propre plateforme viable la plus mince véritablement mince, résistant à la tentation de sur-ingénierer pour une échelle que vous n'avez pas encore. Votre voie la plus rapide vers l'accumulation d'une dette technique paralysante est de livrer du code expédient sous pression d'investisseur et de ne jamais le rembourser, donc faites des choix délibérés et visibles sur quelle dette vous prenez. Paradoxalement, concevoir afin qu'un client puisse extraire ses données et partir est ce qui gagne la confiance qui les garde.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, une clinique monosite, ou un petit fournisseur de health-tech ayant dépassé le stade de la startup — porte les mêmes obligations qu'un grand trust mais avec une fraction des ressources et rarement une capacité informatique dédiée. Ici, l'architecture est principalement la discipline de bien acheter : favorisez un logiciel en tant que service réputé afin que le fournisseur porte l'hébergement, les correctifs, et la sécurité que vous ne pouvez pas doter en personnel vous-même, et lisez le contrat pour les droits d'extraction de données et de sortie avant de signer, car la dépendance mord le plus fort lorsque vous n'avez aucun levier. Gardez un inventaire simple de la poignée de systèmes dont vous dépendez et sachez lesquels sont encore supportés, car même un petit parc peut cacher une machine non corrigée qui arrête le cabinet. Insistez pour que les fournisseurs respectent des normes reconnues telles que le Data Security and Protection Toolkit plutôt que d'essayer d'évaluer la sécurité à partir de zéro. Lorsque la trésorerie est serrée, la tentation est de garder un ancien système non supporté fonctionnant pour éviter une facture, mais c'est une décision de sécurité que vous devriez prendre délibérément, pas par dérive.

Entreprise#

Un grand trust ou fournisseur porte des décennies de systèmes accumulés et ne peut pas simplement recommencer. La stratégie réaliste est une évolution disciplinée : maintenez un portefeuille vivant, placez des couches ouvertes basées sur API devant ce qui doit rester, et remboursez la dette la plus dangereuse selon un plan financé et priorisé plutôt qu'en paniques occasionnelles. Exploitez une autorité de conception qui est respectée car elle habilite la livraison, pas redoutée car elle la bloque, et faites de la dette technique un risque permanent au niveau du conseil d'administration avec un propriétaire nommé. Gardez-vous contre la dépendance à chaque renouvellement, et traitez le désengagement comme un véritable travail doté en ressources plutôt qu'une réflexion après coup. C'est la même discipline de réutilisation et d'interface ouverte qui gouverne les plateformes opérationnelles centrales au Sujet 5.4 — Planification des ressources d'entreprise (ERP).

Gouvernement#

Les organismes nationaux et régionaux fixent les conditions dans lesquelles tout le secteur opère, et leurs choix d'architecture se répercutent vers l'extérieur. Les choses les plus précieuses que le gouvernement puisse faire sont de mandater des normes ouvertes, fournir des plateformes nationales réutilisables afin que les organisations locales construisent une fois, et fixer des attentes de cloud, de sécurité, et de durabilité qui élèvent le plancher partout. Fait crucial, le gouvernement doit financer le travail national peu glamour — remédiation d'héritage, maintenance de terminologie, soutien au désengagement — qu'aucune organisation seule ne financera seule mais dont tout le monde dépend. Une norme fermement appliquée et suffisamment bonne réutilisée largement bat une norme théoriquement supérieure implémentée de manière incohérente. Ce rôle d'intendance se connecte au Sujet 9.1 — Travailler avec les gouvernements locaux et nationaux et à comment les partenaires collaborent au Sujet 9.0 — Collaborer avec les organisations partenaires.

Modes d'échec courants#

• Parc invisible. Exploiter des centaines d'applications sans inventaire précis, de sorte que l'exposition est inconnue, la duplication passe inaperçue, et le premier signe de fragilité est une panne ou une brèche.
• Dette cachée du conseil d'administration. Garder le logiciel non supporté et la dette technique comme une note de bas de page technique plutôt qu'un risque d'entreprise nommé, de sorte qu'elle n'est jamais financée jusqu'à ce qu'elle échoue.
• Cloud comme slogan. Faire du lift-and-shift d'un héritage non modifié vers le cloud public par principe, déplaçant le problème à un coût plus élevé, ou entremêlant les données et l'outillage si profondément chez un fournisseur que cela devient une nouvelle dépendance.
• Autorité de conception comme goulot d'étranglement. Laisser la gouvernance d'architecture devenir une porte lente que les équipes contournent, produisant une architecture fantôme non documentée qui est pire que rien.
• Construire quand vous devriez configurer. Choisir des constructions sur mesure pour des besoins de commodité, sur le prix affiché plutôt que le coût total de possession, et hériter d'une décennie de maintenance que vous n'avez pas budgétée.
• Ne jamais désengager. Laisser des systèmes obsolètes fonctionner « juste au cas où », chacun une surface d'attaque, un coût de licence, et un drain de maintenance que personne ne possède.
• Sécurité ajoutée après coup. Traiter la sécurité comme une porte avant lancement plutôt qu'une entrée de conception, de sorte que la surface d'attaque est fixée bien avant que quiconque ne l'évalue.
• Dépendance par défaut. Signer des plateformes sans interfaces ouvertes ni droits d'extraction de données, et découvrir le coût du piège seulement lorsque vous essayez de partir.

Modèle de maturité#

Liste de contrôle#

• Un portefeuille d'applications vivant enregistre le propriétaire, le coût, la supportabilité, et le risque de chaque système, et est révisé régulièrement.
• Les systèmes critiques non supportés et non corrigibles sont identifiés et se trouvent sur le registre des risques d'entreprise, pas dans une feuille de calcul technique.
• Un court ensemble convenu de principes d'architecture est véritablement utilisé pour prendre et justifier des décisions.
• Une autorité de conception révise les décisions significatives et difficiles à inverser et clarifie rapidement les routinières, habilitant plutôt que bloquant.
• L'adoption du cloud est évaluée charge de travail par charge de travail, pesant la résidence, la résilience, le coût, la portabilité, et le carbone.
• La dette technique a un propriétaire nommé et un plan de remédiation financé, pas seulement une lutte occasionnelle contre les incendies.
• Les systèmes dupliqués et obsolètes sont rationalisés, et le désengagement est doté en ressources avec migration de données, conservation, et vérifications de dépendances.
• Les nouvelles capacités exposent des API ouvertes et versionnées afin que les composants puissent être remplacés sans reconstruire autour.
• La sécurité est conçue dès le début — surface d'attaque minimale, moindre privilège, segmentation — pas ajoutée avant le lancement.
• Les décisions construire/acheter/configurer sont prises sur le coût total de possession et la dépendance, avec des droits de sortie et d'extraction de données sécurisés avant de signer.

Sources clés#

• NHS England — cloud strategy, technology standards, and the Data Security and Protection Toolkit.
• National Cyber Security Centre (NCSC) — secure design principles and cloud security guidance.
• UK Government (GDS/CDDO) — the Technology Code of Practice and cloud-first policy.
• National Audit Office — reports on NHS legacy systems, the WannaCry attack, and IT-enabled programmes.
• The Open Group — TOGAF, the enterprise architecture framework.
• Government Digital Service — the "thinnest viable platform" concept in the GOV.UK service manual and design community.

Références#

1. Enterprise architecture — Wikipédia — https://en.wikipedia.org/wiki/Enterprise_architecture
2. Solution architecture — Wikipédia — https://en.wikipedia.org/wiki/Solution_architecture
3. Systems architecture — Wikipédia — https://en.wikipedia.org/wiki/Systems_architecture
4. Cloud computing — Wikipédia — https://en.wikipedia.org/wiki/Cloud_computing
5. Software as a service — Wikipédia — https://en.wikipedia.org/wiki/Software_as_a_service
6. Legacy system — Wikipédia — https://en.wikipedia.org/wiki/Legacy_system
7. Technical debt — Wikipédia — https://en.wikipedia.org/wiki/Technical_debt
8. Application portfolio management — Wikipédia — https://en.wikipedia.org/wiki/Application_portfolio_management
9. Application programming interface — Wikipédia — https://en.wikipedia.org/wiki/Application_programming_interface
10. Total cost of ownership — Wikipédia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
11. Secure by design — Wikipédia — https://en.wikipedia.org/wiki/Secure_by_design
12. Vendor lock-in — Wikipédia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Cloud strategy — NHS England — https://www.england.nhs.uk/long-read/cloud-centre-of-excellence/
14. Secure design principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/cyber-security-design-principles
15. Technology Code of Practice — UK Government (CDDO) — https://www.gov.uk/guidance/the-technology-code-of-practice
16. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
17. TOGAF Standard — The Open Group — https://www.opengroup.org/togaf
18. Service Manual: cloud and platforms — Government Digital Service — https://www.gov.uk/service-manual