Ingénierie logicielle et plateformes du secteur public

Pourquoi cela compte pour la valeur publique

Presque chaque service public qu'un citoyen touche aujourd'hui — enregistrer une naissance, demander une prestation, payer une facture fiscale, réserver une date de tribunal — fonctionne sur un logiciel quelque part derrière le guichet ou l'écran. Ce logiciel est rarement un achat ponctuel ; il devient partie de l'infrastructure permanente de l'État, survivant souvent à l'administration qui l'a commandé, au fournisseur qui l'a bâti, et au langage de programmation dans lequel ses ingénieurs ont été formés. Un organisme public ne vit pas le logiciel de la façon dont il vit un bâtiment ou une route, où la condition de l'actif est visible ; le logiciel se dégrade invisiblement, et la facture pour cette décomposition arrive des années plus tard comme une urgence.

La tension qui mène ce thème est structurelle. Le logiciel est intrinsèquement itératif — les exigences deviennent plus claires à mesure que les utilisateurs interagissent avec un système fonctionnel, et la meilleure pratique d'ingénierie est de bâtir quelque chose de petit, d'apprendre, et de s'adapter. Les cycles d'approvisionnement et de redevabilité publics (voir thème 3.7 — Achats publics et commande de services), en contraste, ont été bâtis pour les travaux d'immobilisation et les contrats de défense : une spécification fixe, une seule grande attribution, des paiements par jalon, et un dossier d'affaires approuvé des années avant que la livraison ne commence. Quand une assemblée législative ou un auditeur attend un contrat à prix fixe et portée fixe et qu'une équipe d'ingénierie a besoin de changer de cap après la première publication, le décalage apparaît comme dérive de portée, dépassement de budget, ou un système spécifié correctement en 2019 et obsolète au moment où il est livré.

Les plateformes que la pratique d'ingénierie de ce thème existe pour bâtir — systèmes d'identité partagés, rails de paiement, outils de gestion de cas réutilisés à travers les départements — sont le sujet du thème 5.1 (voir thème 5.1 — Gouvernement numérique et transformation numérique) ; ce thème porte sur la discipline consistant à bâtir et acheter le logiciel qui rend toute telle plateforme, ou tout service unique, fiable, remplaçable, et possédé par l'organisme public qui en dépend plutôt que par quel que soit le fournisseur qui l'a écrit en premier.

Concepts fondamentaux

La décision de bâtir contre acheter est le choix entre commander un logiciel sur mesure écrit pour le besoin d'une organisation et adopter un logiciel commodité configurable déjà bâti pour un marché d'acheteurs similaires. Acheter est habituellement moins cher et moins risqué pour un besoin qui n'est pas authentiquement distinctif — paie, courriel, gestion de cas standard — tandis que bâtir n'est justifié que là où l'exigence est assez différente pour qu'aucun produit configurable ne convienne, ou là où la capacité elle-même est un actif stratégique que l'organisation a besoin de posséder et de faire évoluer.

La dette technique est une métaphore, forgée par l'ingénieur logiciel Ward Cunningham en 1992, pour le coût accumulé de choisir une façon expéditive de livrer un logiciel maintenant plutôt qu'une façon plus approfondie qui aurait pris plus longtemps. La dette technique, comme la dette financière, n'est pas intrinsèquement mauvaise à contracter — le propre point de Cunningham était que livrer un code fonctionnel rapidement et le refactoriser après coup peut être le bon choix — mais une dette qui n'est jamais remboursée accumule des intérêts sous forme de livraison plus lente, plus de défauts, et de risque croissant, et un organisme public qui ne peut pas voir sa dette ne peut pas décider s'il faut la servir ou la laisser se composer.

Un système hérité est une vieille technologie, application, ou plateforme qui demeure en usage actif malgré être périmée, souvent parce que la remplacer est coûteux ou parce que personne restant dans l'organisation ne comprend pleinement ce qu'elle fait. Les systèmes hérités sont particulièrement persistants au gouvernement : les systèmes centraux de fiscalité, de prestations, et d'assurance sociale écrits il y a des décennies dans des langages tels que COBOL — le Common Business-Oriented Language, conçu en 1960 pour l'informatique administrative — traitent encore des transactions pour des millions de citoyens, parce que les systèmes fonctionnent et que la connaissance institutionnelle nécessaire pour les retirer en sécurité a souvent pris sa propre retraite en premier.

La modernisation logicielle est le terme général pour convertir, réécrire, ou migrer un système hérité vers une architecture, un langage, ou une plateforme actuels. La modernisation logicielle couvre un spectre allant d'une réécriture complète à des options plus conservatrices telles que réhéberger le même code sur une infrastructure moderne, et le choix entre elles est autant une décision de gestion de risque qu'une décision technique.

Le schéma du figuier étrangleur (strangler fig pattern) est une approche de modernisation incrémentale, nommée d'après une liane qui pousse autour d'un arbre hôte et le remplace graduellement, dans laquelle une nouvelle fonctionnalité est bâtie aux côtés d'un système hérité et le trafic y est redirigé pièce par pièce, plutôt que de remplacer tout le système en une seule bascule. Le schéma du figuier étrangleur compte parce qu'il permet à chaque incrément d'être testé, retiré, ou mis en pause sans faire tomber tout le service — l'opposé d'un remplacement en grand-bang, où l'ancien système est éteint et le nouveau allumé en un seul moment sans moyen de retour arrière si quelque chose ne va pas.

La dépendance envers un fournisseur (vendor lock-in) survient quand un client devient si dépendant de la technologie propriétaire, des formats de données, ou des termes contractuels d'un fournisseur que basculer vers un autre fournisseur porte un coût ou risque prohibitif. La dépendance envers un fournisseur est un danger particulier dans le logiciel du secteur public parce que l'acheteur est un client récurrent avec une capacité pratique limitée de partir d'un système faisant fonctionner un service critique, ce qui affaiblit sa position de négociation à chaque renouvellement subséquent.

Le logiciel libre et open source est un logiciel distribué sous une licence qui accorde aux utilisateurs la liberté d'utiliser, d'étudier, de modifier, et de redistribuer le code source. Le logiciel libre et open source sous-tend une politique d'ouverture par défaut, sous laquelle un organisme public se rabat par défaut sur la publication du code source qu'il commande à moins qu'une raison spécifique — sensibilité de sécurité, droits de tiers — ne justifie de le retenir ; le raisonnement est habituellement résumé comme « argent public, code public » : un logiciel payé une fois avec des fonds publics ne devrait pas avoir besoin d'être payé à nouveau, dans une juridiction différente, par un organisme public différent résolvant le même problème.

Un bien public numérique est un logiciel, des données, ou du contenu ouverts, publiés sous une licence ouverte, conçus pour aider à atteindre un objectif de développement ou de gouvernance publique plutôt que générer un retour commercial. Les biens publics numériques recadrent la publication open source d'un gouvernement comme partie d'une infrastructure plus large et partagée sur laquelle d'autres gouvernements et organisations de la société civile peuvent s'appuyer directement, non seulement un geste de transparence interne.

Le développement logiciel agile est un terme parapluie pour les approches itératives de bâtir des logiciels qui favorisent le logiciel fonctionnel, la livraison fréquente, et la réponse au changement plutôt que suivre un plan fixe convenu à l'avance. Le développement logiciel agile contraste avec le modèle en cascade, une approche séquentielle dans laquelle les exigences, la conception, la construction, et le test se complètent chacun entièrement avant que le suivant ne commence ; l'attrait de la cascade pour les organismes publics a toujours été que ses jalons se mappent proprement sur un contrat à prix fixe et un cycle budgétaire annuel, ce qui explique pourquoi tant de droit de l'approvisionnement le suppose encore, même là où la livraison est authentiquement agile.

Un produit viable minimal est la plus petite version d'un service qui peut être publiée à de véritables utilisateurs pour tester si elle fonctionne et apprendre quoi bâtir ensuite. Le concept de produit viable minimal, adapté dans les manuels de service numérique du secteur public, donne à une équipe itérative une façon défendable de montrer à un bailleur de fonds ou un auditeur quelque chose de réel et fonctionnel bien avant que la portée complète ne soit terminée — pourvu que le processus de redevabilité accepte une publication authentiquement minimale plutôt que de la traiter comme le produit fini sous un autre nom.

Pratiques exemplaires

1. Rabattez-vous par défaut sur l'achat pour les besoins non différenciés, et réservez la construction pour ce qui est authentiquement distinctif. Les besoins de paie, de courriel, et de gestion de cas générale sont rarement assez différents de ceux de toute autre organisation pour justifier un logiciel sur mesure ; ne bâtissez que là où l'exigence, l'échelle, ou le besoin de posséder et de faire évoluer la capacité sur des décennies est authentiquement différent de ce que le marché offre.
2. Rendez la dette technique visible avant de décider combien en porter. Maintenez un registre des raccourcis connus, des corrections différées, et des dépendances non supportées pour chaque système en service, révisé selon un cycle fixe, afin que porter la dette pour une autre année soit un arbitrage délibéré plutôt que personne ne regardant.
3. Ne planifiez jamais une bascule unique et irréversible comme la seule voie hors d'un système hérité critique. Préférez des approches incrémentales telles que le schéma du figuier étrangleur qui permettent à chaque pièce d'être testée, inversée, et déployée graduellement ; un remplacement en grand-bang d'un système dont des millions dépendent concentre des années de risque en un seul week-end sans moyen de retour arrière si quelque chose échoue.
4. Traitez le code source que votre organisation paie pour faire écrire comme un actif qu'elle possède, non un service qu'elle loue. Négociez l'entiercement du code source ou la propriété directe au point de contractualisation, non après qu'un litige n'ait commencé, puisqu'un fournisseur détenant la seule copie du code de votre service critique est une dépendance envers un fournisseur par conception.
5. Publiez le code source comme ouvert par défaut, et exigez une justification spécifique pour le retenir. Une politique d'ouverture par défaut, appliquée de façon cohérente, transforme le logiciel sur mesure de chaque département en un actif partagé à travers le gouvernement plutôt qu'un coût ponctuel, et permet à des experts externes de trouver des failles de sécurité qu'une équipe interne seule manquerait.
6. Écrivez des contrats logiciels qui rendent la livraison itérative légale, non seulement techniquement possible. Un contrat qui ne paie que contre une spécification fixe convenue à la signature force une équipe à choisir entre une pratique agile honnête et la conformité contractuelle ; utilisez des portails de financement échelonnés liés à un logiciel fonctionnel démontré plutôt qu'un seul jalon à la fin.
7. Financez la modernisation comme un programme continu, non un projet d'immobilisation ponctuel. Un système hérité modernisé une fois puis laissé pour encore vingt ans accumule le même risque avec lequel il a commencé ; budgétez pour un renouvellement continu et incrémental de la façon dont une autorité routière budgète pour le resurfaçage, non un grand remplacement une fois par génération.
8. Choisissez des normes ouvertes et des formats de données portables même en achetant un logiciel commercial. Exiger que le système d'un fournisseur stocke et exporte des données dans des formats ouverts et documentés garde les coûts de basculement bas même là où le logiciel lui-même est propriétaire, et est souvent une garantie à court terme plus atteignable contre la dépendance qu'insister que chaque système soit open source.
9. Bâtissez un produit viable minimal et montrez-le à de véritables utilisateurs avant de vous engager à la portée complète. Publier une version authentiquement minimale, puis itérer sur ce qui est appris, attrape les mauvaises hypothèses pendant qu'elles sont encore bon marché à corriger, plutôt qu'après qu'un système à grande échelle n'ait été bâti contre elles.
10. Gardez la capacité d'ingénierie interne suffisante pour être un acheteur intelligent, même là où la livraison est sous-traitée. Un organisme public qui a évidé son expertise technique ne peut pas évaluer la proposition d'un fournisseur, repérer les signes d'alerte précoces d'un projet troublé, ou négocier sa sortie de la dépendance, quoi que disent ses règles d'approvisionnement sur papier.
11. Retirez le profil de risque d'un système hérité avant son interface utilisateur. Priorisez le remplacement des langages non supportés, de l'infrastructure non corrigée, et des intégrations non documentées — les échecs qui causent des pannes et des brèches — avant la modernisation visuelle qui porte bien moins de risque opérationnel.
12. Mesurez la santé de la livraison avec des indicateurs d'ingénierie, non seulement l'écart de budget et de calendrier. La fréquence de déploiement, les taux de défauts, et l'âge de l'élément de dette technique non traité le plus ancien disent à un conseil de gouvernance bien plus sur si un programme réussira que si il est actuellement dans le budget, souvent le dernier indicateur à bouger.

Questions à discuter avec votre équipe

Savons-nous réellement combien de dette technique nous portons, système par système ? La plupart des organismes publics peuvent énoncer leur budget d'immobilisation pour l'année mais ne peuvent pas énoncer, avec quelque confiance, combien de leur parc logiciel fonctionne sur des composants non supportés, une logique non documentée, ou du code que personne restant au personnel ne comprend pleinement. Utilisez cette question pour demander à chaque propriétaire de système dans la salle d'estimer, honnêtement, à quel point il est confiant que son équipe pourrait changer en sécurité son système le plus critique sans casser quelque chose que personne n'anticipait. Discutez de ce qu'il faudrait pour transformer ces estimations en un véritable registre, révisé selon un cycle fixe, plutôt qu'une connaissance tribale qui part quand un ingénieur clé le fait. Considérez aussi qui décide actuellement combien de dette il est acceptable de porter, et si cette décision est délibérée ou par défaut.

Si notre système hérité le plus critique devait être remplacé à partir d'aujourd'hui, planifierions-nous une bascule en grand-bang ou une migration incrémentale — et pourquoi ? L'instinct de remplacer un ancien système d'un seul coup est souvent mû par les cycles budgétaires et la commodité de gestion de programme plutôt que la nécessité technique, et il concentre un énorme risque en un seul moment. Utilisez cette question pour parcourir, concrètement, à quoi ressemblerait réellement une migration incrémentale de style figuier étrangleur de votre système hérité le plus critique, pièce par pièce. Discutez de ce qui vous empêche de choisir cette voie aujourd'hui — un financement structuré autour d'une seule date de mise en service, un processus de gouvernance qui veut un jalon propre unique, ou une véritable contrainte technique qui rend la migration incrémentale impossible pour ce système.

Qui possède réellement le code source du logiciel que notre organisation a payé pour faire construire, et pourrions-nous le prouver ? De nombreux organismes publics découvrent, seulement quand une relation avec un fournisseur tourne mal, que le contrat n'a jamais sécurisé une propriété claire ou un entiercement du code dont leurs services critiques dépendent. Utilisez cette question pour sortir les contrats de vos trois systèmes sur mesure les plus importants et vérifier, spécifiquement, ce que chacun dit sur la propriété du code, l'entiercement, et le droit de porter le code à un autre fournisseur. Discutez de ce qui se passerait demain si votre fournisseur principal pour l'un de ces trois systèmes faisait faillite ou refusait de continuer la relation.

Où nous rabattons-nous par défaut sur un logiciel fermé et propriétaire par habitude, quand une approche d'ouverture par défaut nous servirait aussi bien ou mieux ? Les politiques d'ouverture par défaut existent précisément parce que la plupart des organismes publics résolvent des problèmes qui se chevauchent indépendamment, chacun payant le coût complet d'un logiciel qu'un autre organisme public a déjà bâti et aurait pu partager. Utilisez cette question pour identifier un système actuellement en construction ou en spécification et demandez si un équivalent existe déjà comme logiciel open source ailleurs au gouvernement, ou si celui que vous bâtissez pourrait utilement être publié pour que d'autres le réutilisent. Discutez de quelle barrière spécifique — préoccupation de sécurité, habitude d'approvisionnement, absence d'une politique claire — empêche réellement cette réutilisation, plutôt que de supposer que ce n'est pas pertinent ici.

Notre processus d'approvisionnement et de redevabilité permet-il réellement une livraison agile honnête, ou ne fait-il que réétiqueter des jalons en cascade comme des sprints ? Il est courant qu'une équipe fasse fonctionner des cérémonies notionnellement agiles tout en étant encore financée, gouvernée, et rapportée contre une spécification fixe convenue à la signature du contrat, ce qui recrée chaque mode de défaillance de la cascade sous une étiquette agile. Utilisez cette question pour retracer un programme numérique vivant depuis son dossier d'affaires jusqu'à son rapport de gouvernance actuel et demandez si la structure de financement tolérerait que le programme change de direction basé sur ce qu'une véritable publication précoce lui a appris. Discutez de ce qui devrait changer dans comment le programme est financé et rapporté pour que la livraison itérative soit réelle plutôt que cosmétique (voir thème 3.7 — Achats publics et commande de services).

Avons-nous assez de capacité d'ingénierie interne pour être un acheteur intelligent des systèmes dont nous dépendons le plus ? Une organisation qui a sous-traité tout son jugement technique, non seulement sa capacité de livraison, ne peut pas dire si la proposition d'un fournisseur est solide, si un projet se dirige discrètement vers des ennuis, ou quel est réellement un prix juste pour le travail. Utilisez cette question pour demander combien de personnes dans votre organisation pourraient de façon crédible réviser une proposition d'architecture technique pour votre système le plus important, et comment ce nombre a changé au cours des cinq dernières années. Discutez de ce qu'il faudrait pour reconstruire cette capacité là où elle s'est érodée, et ce que votre organisation perd, en position de négociation autant qu'en risque de livraison, pour chaque année où elle s'en passe.

En pratique : un exemple de valeur publique

Un gouvernement régional fictif — illustratif seulement, non une description d'une juridiction réelle — faisait fonctionner ses demandes de prestation de chômage à travers un système écrit pour la première fois il y a plus de trente ans, maintenu par un nombre décroissant d'ingénieurs qui comprenaient son langage de programmation original. Le volume de demandes avait crû bien au-delà de ce que les concepteurs du système avaient anticipé, les traitements nocturnes échouaient de plus en plus à se compléter avant que les transactions du matin ne commencent, et la direction technologique de l'organisme avertissait qu'une panne non planifiée affectant les paiements de prestation était désormais une question de quand, non de si.

Le premier instinct de l'organisme était une réponse conventionnelle à un problème qui semblait urgent : commander un seul grand contrat pour remplacer tout le système par une plateforme moderne, spécifiée en entier à l'avance, livrée contre un calendrier fixe de deux ans avec un week-end de bascule à la fin. Une révision préalable à la mise en œuvre commandée par le comité d'audit de l'organisme a soulevé une question difficile avant que le contrat ne soit signé : que se passerait-il pour les paiements de prestation de plusieurs centaines de milliers de demandeurs si le nouveau système avait un défaut non découvert dans sa première semaine d'opération complète et en direct, avec l'ancien système déjà mis hors service et aucun moyen de retour arrière.

L'organisme a changé de cap. Il a gardé le système hérité fonctionnant comme système de référence et a commencé à bâtir une nouvelle fonctionnalité de prise de demande et d'évaluation d'éligibilité à ses côtés, en utilisant une approche de figuier étrangleur : chaque nouveau module était publié à un petit pourcentage de nouvelles demandes en premier, vérifié contre la sortie parallèle de l'ancien système, et étendu seulement une fois que ses résultats correspondaient. En dix-huit mois, la majorité des nouvelles demandes fonctionnaient à travers des composants modernes tandis que le système original gérait une charge résiduelle décroissante, avec la capacité d'acheminer tout cas unique de retour vers l'ancien chemin si quelque chose semblait mal. L'organisme a aussi exigé, dans chaque nouveau contrat émis pour ce travail, que le code source soit possédé par l'organisme et publié comme open source une fois la révision de sécurité complète, afin que d'autres gouvernements régionaux faisant face au même problème de mainframe vieillissant puissent adapter les composants plutôt que de répéter la même construction à partir de rien.

Le remplacement complet des dernières fonctions résiduelles du système hérité a pris près de quatre ans — plus long, sur papier, que ne le promettait le plan original de grand-bang de deux ans. Mais aucun demandeur n'a jamais vécu une panne non planifiée pendant la transition, chaque incrément était assez petit pour être inversé en quelques heures quand un défaut était trouvé, et deux gouvernements régionaux voisins ont commencé à adapter le code d'évaluation d'éligibilité publié de l'organisme pour leurs propres systèmes dans la première année de sa publication.

Quatre angles sectoriels

Collectivités locales

Les collectivités locales font typiquement fonctionner un grand nombre de systèmes plus petits et déconnectés plutôt qu'une poignée de plateformes à échelle nationale, ce qui signifie que la dette technique s'accumule à travers de nombreuses applications séparément approvisionnées et séparément maintenues plutôt que dans un système phare visible unique. Les collectivités locales ont habituellement la moins de capacité d'ingénierie interne de tout palier de gouvernement, rendant le dossier pour acheter un logiciel commodité configurable plutôt que des constructions sur mesure particulièrement fort, et rendant les plateformes régionales ou nationales partagées — le sujet du thème 5.1 (voir thème 5.1 — Gouvernement numérique et transformation numérique) — une voie particulièrement à haute valeur pour éviter que chaque autorité ne reconstruise séparément la même capacité.

Gouvernement national

Le gouvernement national est où les systèmes hérités les plus anciens et les plus conséquents tendent à se situer — administration centrale de la fiscalité, de l'assurance sociale, et des prestations — parce que ceux-ci étaient souvent parmi les premiers efforts de computérisation à grande échelle au gouvernement et portent maintenant les enjeux les plus élevés pour tout échec de modernisation. Le gouvernement national a typiquement la capacité commerciale et d'ingénierie spécialisée pour faire fonctionner un programme de modernisation authentiquement incrémental et pour négocier une véritable propriété du code dans ses contrats, et c'est habituellement le niveau de gouvernement le mieux placé pour fixer une politique d'ouverture par défaut avec assez d'échelle derrière elle pour rendre la réutilisation à travers le gouvernement réellement possible.

Secteur social et organismes à but non lucratif

Les organismes à but non lucratif et de bienfaisance bâtissent rarement de grandes plateformes personnalisées eux-mêmes, mais ils sont fréquemment du côté récepteur d'un logiciel commandé ou mandaté par un bailleur de fonds gouvernemental — un portail de rapport, un système de gestion de cas qu'une subvention ou un contrat les exige d'utiliser — avec peu d'influence sur sa conception, sa dette technique, ou son fournisseur. Une organisation du secteur social qui dépend d'un système mandaté par le gouvernement hérite des modes de défaillance de ce système sans hériter d'aucun des leviers pour les corriger, ce qui est une raison de plus pour laquelle les relations de financement basées sur les résultats doivent tenir compte du fardeau opérationnel de la technologie mandatée (voir thème 3.7 — Achats publics et commande de services), non seulement la mesure de résultat elle-même.

Organismes multilatéraux et internationaux

Les organismes multilatéraux et les agences de développement promeuvent de plus en plus le logiciel bâti pour l'administration publique d'un pays comme un bien public numérique réutilisable que d'autres pays peuvent adapter, plutôt que chaque gouvernement commandant un système équivalent d'un fournisseur privé à coût complet. Le risque distinctif ici est qu'un bien public numérique bâti pour le contexte légal et administratif d'un pays peut être adopté ailleurs avec trop peu d'adaptation, important des hypothèses — sur l'identité, l'éligibilité, ou le processus — qui ne se transfèrent en réalité pas ; la promesse d'une infrastructure partagée et ouverte est réelle, mais seulement là où une véritable capacité d'adaptation locale accompagne le code.

Modes de défaillance courants

La bascule en grand-bang qui échoue à la mise en service. Un système hérité critique est remplacé en une seule bascule irréversible après des années de développement sans aucune exposition à la production en direct, et un défaut qui n'apparaît qu'à véritable échelle ou dans un cas limite que personne n'a testé fait surface le premier jour d'opération complète, sans moyen de revenir à l'ancien système parce qu'il a déjà été mis hors service. Le coût est mesuré en paiements manqués, services refusés, ou pannes affectant exactement les citoyens que le système existe pour servir, au pire moment possible — le moment où tout le monde comptait sur le fonctionnement du remplacement.

L'accumulation silencieuse de dette technique. La pression d'échéance gagne répétitivement l'argument contre le temps nécessaire pour corriger les raccourcis connus, et chaque report est individuellement défendable, jusqu'à ce que la dette accumulée rende même un petit changement disproportionnément coûteux et risqué. Le coût fait surface des années plus tard comme un système que personne ne peut modifier en sécurité, une main-d'œuvre qui a discrètement cessé de tenter quoi que ce soit sauf les correctifs les plus urgents, et un programme de modernisation éventuel bien plus grand et coûteux qu'un renouvellement continu et plus petit ne l'aurait été.

La dépendance envers un fournisseur confondue avec la stabilité. Un organisme public renouvelle le contrat du même fournisseur répétitivement parce que basculer semble trop perturbateur pour être tenté, sans jamais tester quels seraient réellement les coûts de basculement authentiques ni négocier pour la propriété du code et les formats de données ouverts qui garderaient ces coûts gérables. Le coût est une position de négociation en permanence affaiblie sur le prix et les termes, découverte seulement quand la qualité de service du fournisseur décline ou que sa tarification augmente et que l'organisme public trouve qu'il n'a aucune alternative crédible.

L'agilité cosmétique. Une équipe de livraison adopte les cérémonies agiles — réunions debout, sprints, un carnet — tandis que le contrat sous-jacent, le financement, et la structure de gouvernance supposent encore une spécification fixe et un seul jalon de décision go/no-go, donc l'équipe rapporte la vélocité de sprint tout en livrant réellement contre un plan en cascade en dessous. Le coût est qu'aucun des véritables bénéfices de l'agilité — la rétroaction utilisateur précoce changeant la direction, le risque révélé tôt — ne se matérialise, tandis que l'apparence de pratique moderne rend la rigidité sous-jacente plus difficile à voir et contester pour les organes de supervision.

La politique open source sans plan de maintien. Un organisme public publie du code source pour satisfaire une politique d'ouverture par défaut mais traite la publication comme une étape de conformité ponctuelle, sans dotation en ressources pour réviser les contributions externes, corriger les vulnérabilités, ou maintenir la documentation. Le coût est un dépôt publié qui semble ouvert mais fonctionne comme une impasse non maintenue, ce qui endommage la confiance dans le programme plus large d'ouverture par défaut plus que de ne jamais publier du tout ne l'aurait fait.

Modèle de maturité

Liste de vérification

• Inventoriez la dette technique de chaque système critique et révisez le registre selon un cycle fixe.
• Appliquez un cadre documenté de bâtir contre acheter avant de vous engager à tout nouveau logiciel significatif.
• Pour tout remplacement de système hérité, rabattez-vous par défaut sur une méthode de migration incrémentale et exigez une justification explicite pour une bascule en grand-bang.
• Confirmez la propriété du code source ou les termes d'entiercement dans chaque contrat logiciel avant la signature.
• Publiez le code source sous une politique d'ouverture par défaut, avec un processus d'exception documenté.
• Dotez en ressources la maintenance continue pour chaque dépôt publié sous cette politique, non seulement sa publication initiale.
• Exigez des formats de données ouverts et documentés même là où le logiciel sous-jacent est propriétaire.
• Structurez les portails de financement autour d'un logiciel fonctionnel démontré plutôt qu'un seul jalon à spécification fixe.
• Bâtissez et testez un produit viable minimal avec de véritables utilisateurs avant de vous engager à la portée complète.
• Suivez la fréquence de déploiement, les taux de défauts, et la dette technique en suspens comme indicateurs de gouvernance permanents.
• Évaluez la capacité d'ingénierie interne contre ce qui est nécessaire pour être un acheteur intelligent, et fermez les lacunes identifiées.
• Priorisez l'infrastructure non supportée et les intégrations non documentées avant la modernisation cosmétique.

Sources principales

• GOV.UK Service Standard, Government Digital Service, Royaume-Uni — une norme nationale de service numérique exigeant une livraison itérative et centrée sur l'utilisateur et des normes ouvertes pour les services publics.
• Office of Management and Budget, Federal Source Code Policy (M-16-21), États-Unis — la politique fédérale exigeant que les agences considèrent la réutilisation et la publication open source pour le logiciel gouvernemental développé sur mesure.
• Free Software Foundation Europe, campagne Public Money, Public Code — le raisonnement, développé pour un public européen, pour publier le code source logiciel financé publiquement sous des licences libres et open source.
• Ward Cunningham, « The WyCash Portfolio Management System » (rapport d'expérience OOPSLA 1992) — l'énoncé original de la métaphore de la dette technique.
• Digital Public Goods Alliance — une initiative multipartite maintenant des normes et un registre pour les logiciels, données, et contenus ouverts conçus pour servir des objectifs de développement public.

Références

1. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
2. Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
3. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
4. COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
5. Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
6. Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
9. Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
12. Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
13. Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
14. Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
15. Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
16. 'The WyCash Portfolio Management System' (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
17. Digital Public Goods Alliance — https://digitalpublicgoods.net/