Économie de l'ingénierie logicielle en santé

Pourquoi cela compte en économie de la santé

Chaque organisation de santé moderne est, qu'elle l'admette ou non, un opérateur de logiciel. Dossiers patients, prescription, planification, résultats de laboratoire, demandes de paiement, et surveillance de population fonctionnent tous sur du code — acheté à des fournisseurs, construit en interne, hérité de prédécesseurs, ou assemblé à travers les trois. L'argent en jeu est grand et récurrent : les programmes nationaux de dossiers de santé électroniques ont consommé des milliards de dollars de fonds publics, et les coûts de fonctionnement du logiciel de santé — maintenance, intégration, mises à niveau, sécurité — éclipsent typiquement le prix qui apparaissait dans le dossier d'affaires original. Pourtant la plupart des formations en économie de la santé ne disent rien sur comment le logiciel se comporte comme un actif économique, et la plupart des formations en ingénierie logicielle ne disent rien sur le coût d'opportunité dans un système qui achète aussi des infirmières et des médicaments.

L'écart compte car le logiciel échoue économiquement de façons caractéristiques que les réflexes d'achat ordinaires ne saisissent pas. Un système est acheté sur son prix d'achat et ses fonctionnalités de démonstration ; l'intégration, la migration de données, et le fardeau de maintenance arrivent plus tard, contre des budgets jamais consultés. Une relation fournisseur se durcit en dépendance, aussi chaque renouvellement est-il négocié depuis une position de faiblesse. Les raccourcis pris sous pression de délai s'accumulent invisiblement jusqu'à ce que le système qui fait fonctionner l'hôpital ne puisse plus être changé en toute sécurité — à quel point l'organisation fait face à une facture de modernisation qu'elle n'a jamais planifiée et ne peut différer, car le logiciel porte maintenant un risque clinique. L'histoire des grands programmes de TI de santé, y compris le National Programme for IT du Royaume-Uni (démantelé en 2011 après un coût estimé de quelque 10 milliards de livres), est une histoire de ces dynamiques à l'échelle nationale.

Pour un dirigeant, les enjeux sont triples. D'abord, l'argent : le logiciel est un engagement de vie entière, et l'option bon marché à l'achat est couramment l'option coûteuse sur une décennie. Ensuite, la sécurité : dans un cadre clinique, une panne, une erreur de données, ou un système non maintenable n'est pas un inconvénient mais un danger, avec des coûts qui retombent au Sujet 3.11 — Économie de la qualité et de la sécurité. Troisièmement, la souveraineté : les choix entre construire et acheter, entre systèmes propriétaires et ouverts, et entre interfaces standard et sur mesure déterminent combien de liberté l'organisation aura d'agir dans cinq ans — et la liberté d'action, comme ce livre l'argumente tout du long, est un actif économique.

Concepts fondamentaux

L'ingénierie logicielle est la conception, construction, et maintenance disciplinées du logiciel — et le mot maintenance porte la majeure partie de l'économie. Contrairement à un bâtiment, le logiciel n'est jamais fini : les exigences évoluent, les réglementations changent, les dépendances vieillissent, et les menaces de sécurité évoluent. La maintenance logicielle — travail correctif, adaptatif, et préventif sur un système en service — absorbe communément la majorité du coût de vie d'un système. L'unité d'analyse économique n'est donc jamais l'achat ; c'est le coût total de possession : acquisition plus intégration, migration de données, formation, hébergement, soutien, mises à niveau, sécurité, et mise hors service éventuelle, sur la vie réaliste du système.

Le second concept est la dette technique : le coût futur implicite de choisir une conception expédiente maintenant plutôt qu'une saine. La métaphore est assez exacte pour être utilisée dans une réunion financière. La dette n'est pas intrinsèquement mauvaise — un raccourci délibéré qui livre une capacité nécessaire plus tôt peut être un emprunt rationnel — mais elle accumule des intérêts : chaque changement futur au système coûte plus à cause d'elle, et une dette non gérée compose jusqu'à ce que le changement devienne prohibitivement coûteux ou dangereux. Une organisation de santé qui ne peut voir sa dette technique porte un passif non comptabilisé, exactement comme si elle avait un emprunt non enregistré.

Troisièmement, le système hérité (legacy) : un logiciel qui reste en service au-delà du point où il peut être maintenu économiquement — souvent parce qu'il fonctionne, tout le monde en dépend, et le remplacer est effrayant. Le legacy est de la dette technique à l'échelle organisationnelle, et il présente un vrai problème d'évaluation : les coûts de le garder (maintenance croissante, exposition de sécurité, personnel qui ne peut plus être recruté, améliorations bloquées ailleurs) sont diffus et graduels, tandis que le coût du remplacement est concentré, visible, et politiquement risqué. Les systèmes de santé du monde entier font fonctionner des services critiques sur des logiciels vieux de plusieurs décennies précisément pour cette raison.

Quatrièmement, la dépendance. Le verrouillage fournisseur est la condition dans laquelle changer de fournisseur coûte tant — en migration de données, reformation, réintégration, et perturbation clinique — que l'acheteur a perdu un pouvoir de négociation effectif. En santé cela est aggravé par les données : une décennie de dossiers patients détenus dans un format propriétaire est un otage. Le verrouillage n'est pas un accident ; c'est une stratégie de tarification, et le moment de le tarifer est avant de signer, non au renouvellement. Les contrepoids sont contractuels (droits d'exportation de données, séquestre, assistance à la sortie) et architecturaux — surtout, les normes.

Cinquièmement, l'interopérabilité : la capacité des systèmes à échanger de l'information et à utiliser ce qui est échangé. Son économie est celle de l'effet de réseau — chaque système qui parle une norme commune élève la valeur de chaque autre système qui le fait — ce qui explique pourquoi l'interopérabilité est chroniquement sous-fournie par les marchés : les bénéfices s'accumulent pour le système dans son ensemble tandis que les coûts retombent sur chaque fournisseur et acheteur, et un acteur en place peut profiter de ne pas interopérer. Des normes telles que Fast Healthcare Interoperability Resources (FHIR), la famille HL7 à laquelle elle appartient, et openEHR existent pour abaisser ces coûts d'échange, et les régulateurs — par exemple les États-Unis via les règles de blocage d'information du 21st Century Cures Act, et l'Union européenne via l'Espace européen des données de santé — ont commencé à imposer ce que le marché n'a pas livré.

Sixièmement, le spectre faire-ou-acheter, y compris le logiciel libre — un logiciel dont le code source est librement utilisable et modifiable. Le logiciel libre n'est pas gratuit : le coût de licence disparaît, mais mise en œuvre, hébergement, et intendance demeurent, et quelqu'un doit maintenir le code. Sa distinction économique est différente — il retire la prime de verrouillage et convertit le logiciel en un bien commun que de nombreux acheteurs peuvent cofinancer, ce qui explique pourquoi des plateformes telles que DHIS2 et OpenMRS portent une grande partie de la charge d'information de santé dans les pays à revenu faible et intermédiaire. La décision de construire contre acheter, de même, n'est pas une préférence technologique mais une question de portefeuille : construire là où la capacité est différenciante et l'organisation peut soutenir une équipe d'ingénierie ; acheter là où le besoin est une commodité ; et ne jamais construire ce que vous ne pouvez maintenir.

Enfin, la fiabilité comme quantité économique. Le logiciel clinique fait fonctionner des services où le temps d'arrêt a un coût de santé, aussi les disciplines d'ingénierie qui gardent les systèmes fiables — y compris l'ingénierie de fiabilité de site, qui gère la fiabilité contre des cibles explicites et des budgets pour l'échec acceptable — sont-elles mieux comprises comme achetant une assurance dont la prime est l'effort d'ingénierie. Une fiabilité au-delà de ce dont le cadre clinique a besoin est du gaspillage ; en dessous, le manque est payé en incidents. La machinerie d'évaluation pour tout cela reste le Sujet 2.1 — Évaluation économique et la discipline d'abordabilité du Sujet 2.5 — Impact budgétaire et abordabilité ; ce sujet fournit la structure de coût spécifique au logiciel dont ces méthodes doivent être alimentées. Évaluer un outil numérique comme une intervention de santé — l'application ou le service de télésanté améliore-t-il les résultats à un coût acceptable — relève du Sujet 5.2 — Économie de la santé numérique ; l'économie des modèles d'IA spécifiquement du Sujet 5.3 — Économie de l'IA en santé.

Bonnes pratiques

1. Évaluer le coût total de possession sur la vie réaliste du système, jamais le prix d'achat. Exigez que chaque dossier d'affaires logiciel chiffre acquisition, intégration, migration de données, formation, hébergement, soutien, sécurité, mises à niveau, et mise hors service sur un horizon énoncé — habituellement une décennie ou plus — et nomme quel budget porte chaque ligne récurrente. Des frais de licence comparés à rien ne sont pas un dossier d'affaires ; c'est la pointe visible d'un engagement.

2. Mettre la dette technique aux livres. Faites en sorte que les responsables d'ingénierie maintiennent un registre des raccourcis significatifs et des composants vieillissants dans le patrimoine, avec une estimation honnête de l'intérêt que chacun facture — changements plus lents, risque d'incident plus élevé, améliorations bloquées. Revoyez-le avec le même sérieux qu'un passif financier, et budgétez une part permanente de la capacité d'ingénierie (communément un cinquième à un tiers) pour la rembourser, car le service de dette différé est de la dette composée.

3. Financer la maintenance comme un coût d'exploitation dès le premier jour. Un logiciel qui est « fini » est un logiciel qui se dégrade : les dépendances vieillissent, les menaces évoluent, les réglementations changent. Intégrez le flux de maintenance dans l'évaluation originale et le budget récurrent, et traitez une proposition sans ligne de maintenance comme incomplète — l'argent sera dépensé de toute façon, et la seule question est s'il a été planifié ou extrait par une crise.

4. Tarifer le verrouillage avant de signer, non au renouvellement. Pour chaque achat majeur, chiffrez la sortie pendant que vous avez encore des alternatives : qui possède les données, sous quel format elles peuvent être exportées, quelle assistance de sortie le fournisseur doit fournir, et ce qu'une migration coûterait plausiblement. Négociez des droits d'exportation de données et des interfaces ouvertes dans le contrat, et traitez la résistance d'un fournisseur à ceux-ci comme une information sur la négociation de renouvellement à venir.

5. Acheter l'interopérabilité délibérément, car le marché la sous-fournit. Exigez le support de normes ouvertes — FHIR et ses proches — comme condition d'achat, vérifiez la conformité revendiquée contre vos flux de données réels plutôt qu'une brochure, et refusez les interfaces sur mesure là où une standard existe. Chaque interface propriétaire que vous acceptez est un coût de changement que vous avez donné au fournisseur et une taxe sur chaque intégration future.

6. Décider faire-versus-acheter comme un portefeuille, associé à votre capacité d'ingénierie. Construisez seulement là où la capacité différencie votre service et vous pouvez réalistement recruter, retenir, et financer une équipe pour maintenir ce que vous construisez — un système interne sans équipe soutenue est un système hérité avec des étapes supplémentaires. Achetez pour les besoins de commodité ; envisagez des plateformes open source là où une communauté ou un consortium public les soutient ; et écrivez le plan de soutien dans la décision, quelle que soit la direction.

7. Traiter le logiciel libre comme une option d'achat avec sa propre structure de coût, non comme gratuite. Comparez-le sur le coût total de possession : pas de frais de licence, mais de vrais coûts de mise en œuvre, d'hébergement, de soutien, et d'intendance, portés en interne ou via un fournisseur de soutien. Pesez ses bénéfices distinctifs — pas de prime de verrouillage, code inspectable, capacité de cofinancer un bien commun avec d'autres organismes de santé — et son obligation distinctive : si vous en dépendez, contribuez à le soutenir.

8. Fixer des cibles de fiabilité à partir de la conséquence clinique, et dépenser à la cible. Décidez, service par service, ce qu'une heure de temps d'arrêt coûte réellement — en soins retardés, contournements dangereux, et confiance perdue — et fixez des objectifs de disponibilité et de récupération en conséquence. Puis tenez la dépense d'ingénierie à la cible des deux côtés : payer pour moins de fiabilité que la clinique n'en a besoin achète des incidents, et payer pour plus qu'elle n'en a besoin achète de la surqualité.

9. Planifier le remplacement du legacy avant qu'il ne devienne forcé. Revoyez l'âge et la maintenabilité des systèmes critiques sur un cycle, et commencez le remplacement pendant que l'acteur en place fonctionne encore — une migration exécutée sous échec est le type le plus coûteux. Préférez la migration incrémentale (étranglant l'ancien système interface par interface) aux bascules big-bang, dont le mode d'échec en santé se mesure en cliniques annulées et dossiers perdus.

10. Faire de la migration de données une ligne de premier ordre dans chaque évaluation. Les données patient survivent à chaque système qui les détient, et les déplacer — proprement, complètement, avec la sécurité clinique assurée — est couramment parmi les coûts les plus grands et les plus sous-estimés de toute transition. Chiffrez-la explicitement, testez-la tôt avec de vrais dossiers, et gardez la garde de vos données sous forme exportable tout au long de la vie d'un système afin que la migration ne soit jamais otage du fournisseur sortant.

11. Garder l'ingénierie de sécurité clinique à l'intérieur de l'économie. Le logiciel de santé est un logiciel pertinent pour la sécurité : les changements ont besoin de tests, les versions ont besoin de chemins de retour arrière, les incidents ont besoin d'investigation, et les juridictions imposent de plus en plus des normes formelles de risque clinique aux TI de santé. Ces disciplines coûtent du temps d'ingénierie et appartiennent au dossier d'affaires — une livraison « moins chère » qui les saute transfère le coût aux patients comme du risque (le coût du préjudice est le Sujet 3.11 — Économie de la qualité et de la sécurité).

12. Acheminer les décisions logicielles à travers le même examen de valeur que tout autre investissement de santé. Un programme logiciel rivalise pour le même budget contraint que les médicaments et le personnel, aussi doit-il la même discipline : un bénéfice énoncé, un vrai comparateur (y compris « améliorer ce que nous avons »), un profil d'abordabilité dans le temps, et une revue post-mise en œuvre contre les promesses faites (la machinerie est le Sujet 2.1 — Évaluation économique et le Sujet 2.5 — Impact budgétaire et abordabilité, et l'art de l'achat le Sujet 3.10 — Achat stratégique et commissionnement).

Questions à discuter avec votre équipe

1. Que coûte réellement notre patrimoine logiciel par an, et quelle part de cela avons-nous planifiée ? La plupart des organisations peuvent nommer leurs frais de licence mais pas leurs coûts d'intégration, de maintenance, de sécurité, et de contournement, qui se cachent dans les budgets opérationnels et le temps de personnel à travers l'organisation. Demandez à l'équipe d'assembler le vrai chiffre annuel pour la poignée de systèmes principaux et de le comparer à ce que les dossiers d'affaires originaux promettaient. La tension est que les coûts diffus n'ont aucun propriétaire unique, aussi personne n'est redevable de leur croissance, et les personnes qui ont approuvé l'achat sont rarement celles qui paient l'entretien. Une réponse honnête produit un chiffre de vie entière, nomme quels budgets le portent, et admet où la dépense est non planifiée — car un coût que vous découvrez annuellement en arriéré est un coût que vous ne pouvez gérer.

2. Où se trouve notre dette technique, et quel intérêt payons-nous dessus ? Les équipes d'ingénierie savent habituellement exactement où se trouve la dette — le module que personne n'ose toucher, l'interface tenue par des étapes manuelles, la plateforme deux versions en retard sur le support de sécurité — mais la connaissance atteint rarement le conseil en langage économique. Demandez le registre : les dettes significatives, ce que chacune ralentit ou met en danger, et ce que la rembourser coûterait. La tension est que le remboursement de dette rivalise avec de nouvelles fonctionnalités visibles et perd toujours sur l'apparence, ce qui est précisément comment la dette compose. Une réponse honnête quantifie l'intérêt (livraison plus lente, exposition aux incidents, projets bloqués), engage une part permanente de capacité pour la réduction, et accepte que porter une certaine dette est rationnel — à condition qu'elle soit portée sciemment.

3. Si nous devions quitter notre principal fournisseur de système dans trois ans, pourrions-nous — et que cela coûterait-il ? Cette question fait surgir le verrouillage pendant qu'il y a encore le temps de le réduire. Sondez qui possède les données et sous quel format elles peuvent partir, ce que le contrat dit sur l'assistance de sortie, combien d'interfaces sur mesure devraient être reconstruites, et quelle reformation et perturbation clinique une migration imposerait. La tension est que tout le monde espère ne jamais exercer la sortie, aussi personne ne veut-il payer pour la garder ouverte — pourtant une sortie impossible est une négociation de renouvellement déjà perdue. Une réponse honnête tarife la sortie, identifie les deux ou trois actions qui la rendraient moins chère (droits d'exportation de données, interfaces standard, documentation), et traite ce prix comme une position de négociation que l'organisation maintient activement.

4. Quels systèmes devrions-nous construire, lesquels devrions-nous acheter, et notre capacité d'ingénierie correspond-elle à cette réponse ? La division construire-versus-acheter est une décision de portefeuille que de nombreuses organisations font par accrétion plutôt que par choix, finissant par construire des commodités et acheter ce qui les différencie. Demandez lesquels de vos systèmes incarnent véritablement quelque chose de distinctif sur votre service et lesquels sont des besoins de commodité qu'un marché ou une communauté open source sert déjà. Puis testez l'affirmation de capacité : pour tout ce qui est construit en interne, y a-t-il une équipe financée et recrutable engagée à le maintenir pour sa vie — pas seulement le projet qui l'a créé ? La tension est que construire flatte l'ambition et acheter flatte la prudence, et aucun des deux instincts n'est une analyse. Une réponse honnête nomme les différenciateurs, admet où les constructions passées devraient être retirées ou remplacées par des produits standard, et refuse de commencer toute construction dont la maintenance est non financée.

5. Que coûte réellement une heure de temps d'arrêt dans notre système le plus critique, et notre dépense de fiabilité y correspond-elle ? Les décisions de fiabilité sont souvent prises par des ingénieurs sans information de coût clinique, ou par des conseils sans information de coût d'ingénierie, aussi la dépense correspond-elle à l'habitude plutôt qu'à la conséquence. Travaillez à travers un scénario concret : le dossier électronique est en panne à travers une journée chargée — qu'est-ce qui est retardé, quels contournements dangereux apparaissent, quel préjudice suit plausiblement, que coûte la récupération ? Puis comparez cela à ce que vous dépensez en résilience, sauvegardes, basculement, et réponse aux incidents. La tension va dans les deux sens : sous-dépenser achète des incidents, mais surqualifier un système à faible enjeu gaspille de l'argent dont un autre service a besoin. Une réponse honnête fixe une cible explicite de disponibilité et de récupération par service critique, dérivée de la conséquence clinique, et peut montrer la dépense d'ingénierie qui l'atteint — ni plus, ni moins.

6. Quel est notre plan pour les systèmes hérités que tout le monde a peur de toucher ? Chaque organisation de santé mature les a : des systèmes au-delà de la maintenabilité économique, gardés en vie car ils fonctionnent et le remplacement est effrayant. Nommez les vôtres. Demandez ce que chacun bloque — intégrations non construites, améliorations non faites, exposition de sécurité portée — et quel est le chemin de remplacement : migration incrémentale, remplacement complet, ou rétention délibérée et planifiée avec risque contenu. La tension est temporelle : les coûts de garder le legacy sont diffus et annuels tandis que le coût de le remplacer est concentré et visible sur la carrière, aussi le report d'apparence rationnelle est-il le défaut jusqu'à ce que l'échec force la question au pire prix possible. Une réponse honnête planifie le remplacement pendant que l'acteur en place fonctionne encore, préfère la migration incrémentale de type étrangleur à la bascule big-bang, et traite « nous déciderons l'an prochain » comme la décision qu'elle est réellement.

En pratique : un exemple d'économie de la santé

Le ministère de la Santé d'un pays fictif d'Afrique de l'Est fait face à une décision de renouvellement. Depuis neuf ans, ses hôpitaux régionaux font fonctionner un système d'information hospitalier propriétaire fourni par un fournisseur étranger. Le système fonctionne, mais le devis de renouvellement a nettement augmenté, chaque nouvelle interface — vers le régime national d'assurance, vers le réseau de laboratoire — est un projet sur mesure tarifé par le fournisseur, et le contrat est silencieux sur l'exportation de données. Pendant ce temps, les bureaux de santé de district du ministère font déjà fonctionner DHIS2, la plateforme open source utilisée pour les statistiques de santé nationales, et un pays voisin a mis en œuvre une plateforme de dossier médical open source avec un consortium de soutien régional.

L'unité d'économie de la santé du ministère recadre la décision de « renouveler ou non » à une comparaison de vie entière de trois options sur dix ans : renouveler l'acteur en place, renouveler à court terme tout en construisant des droits de sortie, ou migrer incrémentalement vers la plateforme open source. Chiffrer les options expose la vraie économie. La licence de l'acteur en place n'est qu'un tiers de son vrai coût annuel une fois les interfaces sur mesure, les projets de mise à niveau obligatoires, et les voyages de soutien étranger comptés. L'option open source ne porte aucune licence mais exige que le ministère finance une équipe de soutien nationale, un hébergement régional, et une contribution à la communauté de la plateforme — de l'argent réel et récurrent que la rhétorique du « logiciel gratuit » avait caché. La ligne décisive, cependant, n'est ni l'une ni l'autre : c'est la migration de données. Neuf ans de dossiers patients se trouvent dans un schéma propriétaire, et le prix du fournisseur pour l'assistance d'extraction est, en effet, le prix de partir.

L'unité tarife la sortie malgré tout, et le chiffre change la négociation. Armé d'une alternative chiffrée, le ministère négocie un renouvellement de deux ans à un prix plus bas qui inclut l'exportation contractuelle de données dans un format documenté et des interfaces FHIR standard vers le régime d'assurance et le réseau de laboratoire — achetées, en termes économiques, comme une option sur une sortie future moins chère, valorisée de la façon dont le Sujet 3.12 — Économie de la préparation aux pandémies et aux urgences valorise toute option sur la liberté d'action future. Pendant ces deux ans, un pilote migre trois hôpitaux de district vers la plateforme open source, testant le consortium de soutien, l'outillage de migration de données, et — élément crucial — si le ministère peut recruter et retenir les ingénieurs dont la plateforme a besoin, s'appuyant sur l'économie de personnel du Sujet 3.6 — Personnel de santé et marchés du travail.

Le pilote réussit dans deux hôpitaux et peine dans le troisième, où les lacunes de personnel transforment chaque incident en crise — un avertissement sur la capacité, non le logiciel. Le ministère procède à une migration nationale échelonnée sur cinq ans, hôpital par hôpital, gardant l'acteur en place fonctionnant en parallèle jusqu'à ce que les données de chaque site soient vérifiées. L'évaluation finale rend la leçon explicite : le mouvement gagnant n'était pas de choisir l'open source par-dessus le propriétaire, mais de tarifer toute la vie de chaque option, d'acheter des droits de sortie avant que la dépendance ne se durcisse davantage, et d'associer l'engagement d'ingénierie à ce que le ministère pouvait réellement soutenir.

Quatre angles sectoriels

Jeune pousse

Une jeune pousse de logiciel de santé vit l'économie de ce sujet du côté vendeur : sa valorisation récompense la vitesse de livraison, ce qui est précisément comment la dette technique s'accumule, et son modèle de revenu peut discrètement dépendre du verrouillage auquel ses clients devraient résister. La discipline est de prendre la dette délibérément — un raccourci qui gagne un client pivot peut être rationnel — tout en gardant un registre et un plan de remboursement, car une base de code qui ne peut être changée est une entreprise qui ne peut pivoter. L'interopérabilité est de la stratégie, non de la conformité : les interfaces standard (FHIR par-dessus tout) sont comment un petit produit gagne une place à l'intérieur de patrimoines dominés par des acteurs en place. Et l'ingénierie de sécurité clinique n'est pas de la bureaucratie à différer jusqu'à l'échelle ; un seul incident d'intégrité de données dans un cadre clinique peut mettre fin à une jeune entreprise.

Petite entreprise

Un petit prestataire établi — un groupe de cliniques, une chaîne de pharmacies, un laboratoire de diagnostic — achète presque tout son logiciel et n'a pas de personnel d'ingénierie pour compenser un mauvais achat, aussi son économie est-elle l'économie de la dépendance. Le coût total de possession et les droits de sortie comptent plus ici que partout ailleurs, car un système mal tarifé est proportionnellement une plus grande part du budget et une migration échouée peut arrêter l'entreprise. La posture sensée est la standardisation : produits grand public, interfaces à normes ouvertes, services hébergés plutôt que serveurs auto-gérés, et contrats lus pour les clauses d'exportation de données avant le prix. Son risque distinctif est le legacy silencieux — le système de gestion de cabinet qui vieillit sur place jusqu'à ce que son fournisseur ferme — aussi même un petit acheteur devrait-il savoir, chaque année, ce qu'il coûterait de quitter chaque système dont il dépend.

Entreprise

Un grand groupe hospitalier ou assureur fait fonctionner des centaines de systèmes, aussi son problème est-il le portefeuille : des produits se chevauchant achetés par différents départements, une toile d'intégration que personne ne cartographie pleinement, et de la dette technique distribuée à travers un patrimoine trop grand pour qu'une seule équipe le voie. L'entreprise mature gère le patrimoine comme elle gère un portefeuille d'investissement — un inventaire de systèmes avec propriétaires, coûts de vie entière, notations de dette et de risque, et horizons de remplacement planifiés — et finance une capacité d'ingénierie permanente pour l'intégration, la fiabilité, et le remboursement plutôt que de traiter chaque amélioration comme un projet à mettre en concurrence. L'échelle lui donne aussi un pouvoir d'achat que le petit acheteur n'a pas : elle peut exiger des interfaces standard, des droits d'exportation de données, et un séquestre comme conditions d'entrée, et ses choix architecturaux disciplinent ses fournisseurs plutôt que l'inverse.

Gouvernement

Un ministère ou un payeur national façonne cette économie pour tous les autres. Il fixe les règles d'interopérabilité qui déterminent si le marché récompense ou punit l'ouverture — comme les États-Unis l'ont fait avec les dispositions de blocage d'information du 21st Century Cures Act et l'Union européenne avec l'Espace européen des données de santé — et son propre achat enseigne aux fournisseurs ce que les acheteurs toléreront. Son mode d'échec distinctif est le méga-programme national : une livraison logicielle centralisée, big-bang, calendarisée politiquement dont l'effondrement se mesure en milliards, comme le National Programme for IT du Royaume-Uni l'a démontré. La discipline est la posture inverse — normes et plateformes centralement, livraison incrémentalement, avec des options open source et localement maintenables pesées sérieusement là où les marchés commerciaux sont minces (la machinerie politique est le Sujet 3.2 — Politique de santé, et l'art de l'achat le Sujet 3.10 — Achat stratégique et commissionnement).

Erreurs courantes

• Acheter la licence, non la vie. Approuver un logiciel sur le prix d'achat pendant que intégration, migration, maintenance, et sortie restent non chiffrées. Remède : exiger le coût total de possession de vie entière, avec des budgets nommés pour chaque ligne récurrente, dans chaque dossier d'affaires.

• Dette invisible jusqu'à ce qu'elle compose. Laisser la dette technique s'accumuler non enregistrée jusqu'à ce que le patrimoine ne puisse plus être changé en toute sécurité. Remède : garder un registre de dette, le rapporter en termes économiques, et engager une capacité permanente au remboursement.

• Glisser somnambuliquement dans le verrouillage. Accepter des formats propriétaires et des interfaces sur mesure jusqu'à ce que la sortie soit inabordable et les renouvellements dictés. Remède : négocier des droits d'exportation de données et des interfaces standard à l'achat, et tarifer la sortie annuellement.

• Construire ce que vous ne pouvez maintenir. Commander des systèmes internes sans équipe financée pour leur vie entière. Remède : aucune construction sans plan de soutien ; acheter ou adopter des plateformes open source là où la capacité est mince.

• Traiter le logiciel libre comme gratuit. Adopter des plateformes communautaires sans financer l'hébergement, le soutien, et l'intendance. Remède : évaluer le logiciel libre sur le coût total de possession et budgéter le soutien dont il a besoin.

• La fiabilité par espoir. Laisser les cibles de disponibilité non fixées jusqu'à ce qu'une panne révèle le coût clinique du temps d'arrêt. Remède : fixer des objectifs de disponibilité et de récupération par service critique à partir de la conséquence clinique, et dépenser à la cible.

• Remplacement de legacy big-bang sous contrainte. Différer la modernisation jusqu'à ce que l'échec force une bascule complète et précipitée. Remède : planifier le remplacement pendant que l'acteur en place fonctionne, et migrer incrémentalement avec fonctionnement parallèle et données vérifiées.

• Logiciel hors de la discipline de valeur. Laisser les programmes de TI sauter l'examen appliqué aux médicaments et services. Remède : mêmes règles — bénéfice énoncé, vrai comparateur, profil d'abordabilité, revue post-mise en œuvre.

Modèle de maturité

Liste de vérification

• Évaluer chaque décision logicielle sur le coût total de possession sur sa vie réaliste, avec des budgets nommés pour chaque ligne récurrente.
• Maintenir un registre de dette technique, le rapporter en termes économiques, et engager une capacité d'ingénierie permanente au remboursement.
• Financer la maintenance comme un coût d'exploitation planifié dès le dossier d'affaires original.
• Négocier des droits d'exportation de données, des interfaces standard, et une assistance de sortie dans les contrats à l'achat.
• Tarifer la sortie de chaque système majeur annuellement, et garder une alternative chiffrée vivante avant les renouvellements.
• Exiger une conformité vérifiée aux normes ouvertes (par ex. FHIR) comme condition d'achat.
• Décider faire-versus-acheter comme un portefeuille, et ne commencer aucune construction sans plan de soutien de vie entière financé.
• Évaluer les options open source sur le coût total de possession, budgétant hébergement, soutien, et intendance.
• Fixer des cibles de disponibilité et de récupération par service critique à partir de la conséquence clinique, et associer la dépense à celles-ci.
• Planifier le remplacement de legacy pendant que les acteurs en place fonctionnent encore, préférant la migration incrémentale à la bascule big-bang.
• Chiffrer et tester la migration de données tôt, et garder les données patient exportables tout au long de la vie de chaque système.
• Acheminer les programmes logiciels à travers le même examen de valeur que tout autre investissement de santé, avec une revue post-mise en œuvre.

Sources clés

• WHO, Global Strategy on Digital Health 2020–2025 — the World Health Organization's frame for digital health investment, including sustainability and interoperability principles.
• HL7 International — the FHIR (Fast Healthcare Interoperability Resources) standard, the dominant open standard for health-data exchange.
• openEHR, DHIS2, and OpenMRS — open-source health-information platforms and specifications widely deployed worldwide, exemplars of community-sustained health software.
• U.S. Office of the National Coordinator for Health IT (now ASTP) — 21st Century Cures Act information-blocking and interoperability rules, a regulatory response to under-supplied interoperability.
• DORA, Accelerate State of DevOps reports — long-running research linking software delivery and reliability practices to organizational performance.
• UK National Audit Office — reports on the National Programme for IT in the NHS, the canonical case study of large-scale health-IT programme failure.

Références

1. Software engineering — Wikipedia — https://en.wikipedia.org/wiki/Software_engineering
2. Software maintenance — Wikipedia — https://en.wikipedia.org/wiki/Software_maintenance
3. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
4. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
5. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
6. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
7. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
8. Network effect — Wikipedia — https://en.wikipedia.org/wiki/Network_effect
9. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
11. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
12. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
13. World Health Organization — Global Strategy on Digital Health 2020–2025 — https://www.who.int/publications/i/item/9789240020924
14. HL7 International — FHIR specification — https://hl7.org/fhir/
15. National Audit Office — The National Programme for IT in the NHS: an update on the delivery of detailed care records systems — https://www.nao.org.uk/reports/the-national-programme-for-it-in-the-nhs-an-update-on-the-delivery-of-detailed-care-records-systems/
16. National Programme for IT — Wikipedia — https://en.wikipedia.org/wiki/National_Programme_for_IT