10.4 Soutenir les systèmes grands et de longue durée

Vue d’ensemble et motivation

La plupart des écrits sur l’ingénierie logicielle parlent de construire de nouvelles choses. Mais la plupart du logiciel important du monde est vieux, grand, et fonctionne toujours : systèmes fiscaux, paiements de prestations, contrôle du trafic aérien, banque centrale, contrôle industriel, et l’infrastructure de la vie quotidienne. Ces systèmes fonctionnent routinièrement pendant dix, vingt, ou trente ans. C’est bien plus long que le mandat de quiconque les a construits, et souvent plus long que les entreprises et langages qui les ont produits. Soutenir de tels systèmes signifie les garder fiables, sécurisés, compris, et capables de changer, à travers des décennies et à travers des générations de personnel. C’est l’une des disciplines les plus difficiles et les moins glamoureuses du domaine, et une où les grandes entreprises et gouvernements portent le fardeau le plus lourd.

Pourquoi cela compte-t-il davantage pour les grandes organisations ? La continuité d’obligation. Une jeune pousse peut réécrire ou abandonner son logiciel. Un gouvernement national ne peut pas arrêter de payer les pensions pendant qu’il refactorise. Les entreprises et agences possèdent des systèmes dont l’échec a des conséquences mesurées en moyens de subsistance, sécurité, ou confiance publique. Et elles en possèdent beaucoup à la fois, dotés en personnel qui rejoint et part sur des décennies. Les menaces centrales ne sont pas exotiques. Ce sont l’érosion lente des gens qui comprennent le système (facteur bus, combien peu de personnes devraient partir avant que la connaissance d’un système ne soit perdue), l’accumulation de connaissance non documentée dans quelques têtes, la décomposition de la pile technologique vers la fin de vie, et la paralysie qui s’installe quand un système devient trop critique pour toucher et trop mal compris pour changer en sécurité.

Ce chapitre parle d’intendance : le travail délibéré et peu glamoureux d’aider un système à survivre gracieusement à ses auteurs. Il couvre la continuité de propriété et l’atténuation du facteur bus, la dépréciation et le démantèlement planifiés, le transfert de connaissance, les défis particuliers des systèmes de décennies, et l’équilibrage constant entre innover et préserver la stabilité dont les citoyens et clients dépendent.

Principes clés

Chaque système critique a besoin d’un propriétaire, toujours. La propriété est une assignation continue, pas un souvenir de qui l’a écrit.
La connaissance qui vit dans une seule tête est un risque, pas un atout. Institutionnalisez la compréhension avant que la personne ne parte.
L’ennui est une fonctionnalité. Pour les systèmes critiques de longue durée, la stabilité et la prévisibilité surpassent souvent la nouveauté.
Planifiez la fin au début. Chaque système sera retiré ou remplacé ; concevez et documentez pour ce jour.
Le changement est comment vous restez en sécurité. Un système trop effrayant pour toucher échoue déjà ; la capacité de changer est un trait de survie.
La continuité survit aux individus. Concevez équipes, documentation, et processus pour qu’aucun départ unique ne soit une crise.
La confiance est le vrai produit. Pour les systèmes orientés citoyen et client, la fiabilité et l’équité soutenues dans le temps sont la mission.

Recommandations

Établir l’intendance et la continuité de propriété

Assignez une propriété explicite et actuelle pour chaque système qui compte. Possédez au niveau de l’équipe, pas au niveau individuel, pour que la propriété survive aux départs. Maintenez un catalogue de service qui enregistre, pour chaque système, qui le possède, ce qu’il fait, dont il dépend, et à quel point il est critique. Révisez la propriété régulièrement, et ne laissez jamais un système devenir orphelin. Un système critique non possédé est une urgence en attente de se produire. Quand les équipes se réorganisent, transférez la propriété délibérément, avec un transfert, pas par supposition. Pour les systèmes de longue durée les plus critiques, assurez-vous que la propriété inclut non seulement l’exploitation mais la capacité de comprendre et changer le système, pour que l’intendance ne se décompose pas en simple gardiennage.

Atténuer le facteur bus et le risque de personne clé

Mesurez et réduisez activement la concentration de connaissance. Si une seule personne peut déployer, déboguer, ou changer un système, c’est un point unique de défaillance aussi réel que tout matériel. Réduisez-le à travers le jumelage et la rotation, la revue de code obligatoire, l’astreinte partagée, et une règle délibérée selon laquelle aucune tâche critique n’a exactement une personne capable. Formez de façon croisée pour qu’au moins deux (idéalement trois) personnes puissent effectuer chaque fonction essentielle. Traitez le départ d’une personne clé comme un événement prévisible que vous préparez continuellement, pas un choc que vous absorbez. La documentation aide. Mais la connaissance de travail répartie à travers une équipe par la pratique réelle est bien plus durable que des documents que personne n’a exercés.

Institutionnaliser le transfert de connaissance

Capturez la connaissance qui partirait autrement avec les gens. Concentrez-vous d’abord sur la connaissance difficile à reconstruire : pourquoi les décisions ont été prises, quelles alternatives ont été rejetées et pourquoi, où sont les bords tranchants et les correctifs critiques dont le reste du système dépend silencieusement, et comment le système se comporte sous stress. Utilisez des enregistrements de décision d’architecture pour préserver le raisonnement derrière les choix, pas seulement les choix. Gardez les livres d’exécution et la documentation opérationnelle proches du système, et exercez-les régulièrement pour qu’ils restent vrais. Construisez des chemins d’intégration qui amènent les nouveaux intendants à une véritable compétence. Traitez les départs comme des événements de transfert de connaissance avec du vrai temps de passation. Souvenez-vous que la connaissance tacite, le ressenti pour un système, se transfère principalement en faisant aux côtés de quelqu’un qui l’a, donc chevauchez les intendants partants et arrivants où vous le pouvez.

Gérer la dépréciation, le démantèlement, et la fin de vie

Planifiez les fins délibérément. Quand vous décidez de retirer ou remplacer un système, traitez le démantèlement comme un projet à part entière : identifiez chaque consommateur et dépendance, fournissez un chemin de migration et un calendrier réaliste, communiquez clairement et répétitivement, et soutenez les consommateurs à travers la transition. Évitez le piège de faire tourner les anciens et nouveaux systèmes en parallèle pour toujours parce que personne ne fera le travail difficile d’éteindre l’ancien. Assignez une responsabilité explicite pour terminer la mise hors service. Préservez les données, enregistrements, et la capacité de répondre à des questions sur le système retiré longtemps après qu’il ait cessé de fonctionner, spécialement là où des règles de rétention légale s’appliquent. Un démantèlement mal fait laisse des systèmes zombies qui sont non maintenus mais sur lesquels on compte encore : le pire de tous les mondes.

Soutenir les systèmes à travers les décennies

Pour les systèmes qui doivent fonctionner pendant vingt ou trente ans, planifiez de survivre à tout : l’équipe originale, les fournisseurs, l’écosystème de langage, et le matériel. Préférez les normes ouvertes et interfaces documentées aux boîtes noires propriétaires, pour que les futurs mainteneurs aient une chance. Modularisez, pour que les parties puissent être remplacées une à la fois plutôt qu’à travers une réécriture tout-ou-rien trop risquée pour jamais être tentée. Gardez le système continuellement maintenu. Un système gardé à jour par petits pas reste durable. Un système gelé « parce qu’il fonctionne » devient silencieusement non maintenable à mesure que sa pile vieillit hors du support. Gardez aussi les compétences pour l’exploiter : pour la technologie véritablement ancienne, formez délibérément des successeurs plutôt que d’espérer que le dernier expert ne parte jamais à la retraite.

Équilibrer l’innovation avec la stabilité et la confiance

Distinguez les parties de votre parc où la nouveauté crée de la valeur des parties où la stabilité est la valeur. Les systèmes centraux dont les citoyens et clients dépendent quotidiennement récompensent habituellement la fiabilité, la compatibilité ascendante, et le changement prudent plutôt que des réécritures excitantes. Investissez l’innovation aux marges (nouveaux canaux, nouvelles fonctionnalités, nouvelles interfaces) tout en gardant le noyau durable stable et bien compris. Changez le noyau, oui, mais par incréments petits, réversibles, et bien testés plutôt que par sauts héroïques. Le but est un système à la fois fiable et capable d’évoluer : jamais si gelé qu’il pourrit, jamais si bousculé qu’il devienne peu fiable.

Compromis : avantages et inconvénients

Approche	Avantages	Inconvénients
Garder et maintenir l’ancien système	Préserve la connaissance institutionnelle ; faible perturbation ; fiabilité éprouvée	Pile vieillissante ; compétences rares ; risque croissant si non maintenu
Réécriture big bang	Pile fraîche ; élimine les scories accumulées	Taux d’échec très élevé ; perd la connaissance de cas limite durement acquise
Modernisation incrémentale	Réduction de risque continue ; garde le fonctionnement	Lent ; exige un financement et une discipline soutenus
Transfert axé sur la documentation	Enregistrement explicite et consultable	Se décompose si non maintenu ; manque la connaissance tacite
Transfert axé sur les personnes (jumelage/rotation)	Connaissance de travail durable ; équipes résilientes	Coûte la productivité actuelle ; exige une planification délibérée
Geler le noyau critique	Stabilité maximale à court terme	La pile vieillit vers la non-maintenabilité ; devient trop effrayante pour toucher

Le compromis déterminant est stabilité contre évolution, et les résolutions naïves échouent toutes deux. Gelez un système critique pour le protéger, et vous garantissez qu’il devienne éventuellement non maintenable et dangereux. Réécrivez-le entièrement pour le moderniser, et vous invitez le taux d’échec élevé pour lequel les remplacements big bang sont notoires, et vous jetez des décennies de connaissance de cas limite encodée dont personne ne se souvient qu’elle existe. Le chemin durable est le changement continu et incrémental : gardez le système vivant et en mouvement par petits pas, pour qu’il ne vieillisse jamais hors du support et n’ait jamais besoin d’un saut terrifiant. Le transfert de connaissance est un compromis similaire, entre la facilité des documents et la durabilité de l’expérience vécue. La réponse est les deux : la connaissance vécue et tenue par l’équipe comme épine dorsale, et les documents comme référence.

Questions à discuter avec votre équipe

Lesquels de vos systèmes critiques n’ont aucun propriétaire d’équipe nommé et actuel en ce moment ? La propriété est une assignation continue, pas un souvenir de qui a écrit le code, et un système critique non possédé est une urgence en attente de se produire, remarquée seulement quand elle casse. Parcourez votre catalogue de service (ou construisez-en un) et vérifiez que chaque système enregistre qui le possède, dont il dépend, et à quel point il est critique. Apportez des preuves : choisissez trois systèmes importants et essayez de nommer l’équipe responsable et la dernière fois que la propriété a été révisée. Là où un système est orphelin, ou là où une réorganisation l’a silencieusement laissé tomber, assignez la propriété délibérément avec un vrai transfert plutôt que par supposition. Assurez-vous que la propriété inclut la capacité de comprendre et changer le système, pour que l’intendance ne se décompose pas en simple gardiennage.
Quand vous remplacez un système, qui est responsable d’éteindre réellement l’ancien ? La course en parallèle éternelle est un échec commun et coûteux : les anciens et nouveaux systèmes fonctionnent côte à côte indéfiniment parce que personne ne possède l’arrêt, vous laissant maintenir deux systèmes et obtenir la sécurité d’aucun. Traitez chaque démantèlement comme un projet géré avec une responsabilité nommée pour terminer la mise hors service, une liste cartographiée de consommateurs, un chemin de migration, et un calendrier réaliste. Apportez des preuves : combien de courses parallèles « temporaires » ou de systèmes à moitié retirés tirent encore de la maintenance dans votre parc aujourd’hui ? Préservez les données et enregistrements pour respecter les règles de rétention légale longtemps après que le système ait cessé de fonctionner, mais ne laissez pas la rétention devenir une excuse pour ne jamais terminer. Un démantèlement mal fait laisse des systèmes zombies qui sont non maintenus mais sur lesquels on compte encore, le pire de tous les mondes.
Quelles compétences pour vos systèmes de longue durée le marché du travail cessera-t-il de fournir, et quel est votre plan de succession ? Les systèmes qui fonctionnent pendant vingt ou trente ans survivent à leurs écosystèmes de langage, leurs fournisseurs, et les carrières des gens qui comprennent l’ancienne pile, et le marché ne vous remettra pas fiablement des remplaçants. Réduisez le facteur bus délibérément pour qu’aucune fonction critique n’ait exactement une personne capable, et formez de façon croisée pour qu’au moins deux, idéalement trois, personnes puissent effectuer chaque tâche essentielle. Apportez des preuves : pour chaque système critique vieillissant, comptez combien de personnes peuvent le changer en sécurité et à quel point les plus compétents sont proches de la retraite. La réponse devrait piloter une formation délibérée de successeurs et un vrai chevauchement entre intendants partants et arrivants, parce que la connaissance tacite (le ressenti pour un système) se transfère principalement en faisant aux côtés de quelqu’un qui l’a. Les documents sont la référence ; la connaissance vécue et tenue par l’équipe est l’épine dorsale.
Quand avez-vous changé votre système de longue durée le plus critique pour la dernière fois, et quelqu’un ose-t-il encore le faire ? Un système que personne n’a touché en un an n’est pas stable, il dérive vers le piège du « trop effrayant pour toucher », où chaque changement est craint et donc la pile vieillit silencieusement hors du support. Pour une grande organisation, cela compte parce que la paralysie se compose : plus le gel est long, plus la connaissance s’estompe et plus le changement éventuel inévitable devient risqué. Apportez des preuves : pour chaque système critique, la date du dernier changement délibéré, la taille du plus petit changement que quiconque tenterait aujourd’hui, et si un correctif de dépendance ou de sécurité routinier pourrait être livré cette semaine sans héroïsme. La considération concurrente est réelle, parce que le changement introduit aussi du risque, donc le but n’est pas le bousculement mais une cadence stable de petits pas réversibles et bien testés. Dans les parcs d’entreprise et gouvernementaux, où un noyau gelé peut se trouver sous un service citoyen pendant une décennie, traitez « nous ne le changeons jamais » comme un drapeau rouge plutôt qu’un réconfort, et financez la maintenance continue qui garde l’option de changer vivante.
Quelle part de votre parc fonctionne sur une technologie qui est à ou proche de la fin de vie, et qui suit cette horloge ? Les environnements d’exécution vieillissants, les bases de données non supportées, et les cadriciels hors maintenance sont le mode d’échec lent qui se transforme en crise soudaine le jour où un correctif de sécurité cesse d’arriver. Pour une grande équipe, le danger est que personne ne possède l’horizon : les équipes individuelles corrigent ce qui casse, mais personne ne maintient une vue de portefeuille de quelles piles perdent le support du fournisseur et quand. Apportez des preuves : un inventaire des technologies centrales de chaque système critique, leurs dates de fin de vie ou fin de support publiées, et l’écart actuel entre ce que vous exploitez et ce qui est encore supporté. La tension est entre le coût de la mise à niveau continue et le risque du report, et le report gagne habituellement jusqu’à ce qu’il perde catastrophiquement. Dans les contextes d’entreprise et gouvernementaux, où les cycles de marchés publics et d’accréditation peuvent prendre un an ou plus, une date de fin de vie qui semble lointaine est souvent déjà à l’intérieur de votre délai, donc le travail de succession et de mise à niveau doit commencer bien avant que l’horloge ne s’épuise.
Où dans votre parc la stabilité est-elle la valeur et la nouveauté un passif, et comment gardez-vous cette frontière honnête ? Tous les systèmes ne récompensent pas le même traitement : les systèmes centraux dont les citoyens et clients dépendent quotidiennement récompensent habituellement la fiabilité et le changement prudent, tandis que les marges récompensent l’expérimentation, et confondre les deux gaspille de l’argent ou invite des pannes. Pour une grande organisation, le risque est que l’ambition et les incitations de carrière poussent des réécritures excitantes exactement dans le noyau durable qui devrait rester ennuyeux. Apportez des preuves : une carte de votre parc marquant où la fiabilité est la mission et où la nouveauté crée de la valeur, plus des changements récents qui ont traversé cette ligne dans un sens ou l’autre et ce qu’ils ont coûté. La considération concurrente est que même un noyau stable doit encore évoluer, donc « stable » ne peut pas devenir une excuse pour geler. Dans les contextes d’entreprise et gouvernementaux, liez cette frontière à des niveaux de criticité explicites et une autorité nommée qui peut opposer son veto à une réécriture risquée d’un système que le public ne peut pas se permettre de voir échouer, pour que le jugement ne dérive pas avec quiconque est le plus bruyant ce trimestre.

Regard sectoriel

Jeune pousse. Avec une poignée d’ingénieurs et peu de marge de manœuvre, votre risque de soutien est concentré dans une ou deux personnes qui ont écrit les systèmes que vous ne pouvez pas vous permettre de perdre, comme la facturation ou l’authentification. Ne dépensez presque rien en processus, mais faites les choses bon marché et à haute valeur maintenant : jumelez une seconde personne à travers chaque système critique, écrivez un enregistrement de décision d’architecture d’une page pour les parties surprenantes, et gardez un livre d’exécution que vous utilisez réellement. Résistez à l’envie de réécrire quelque chose juste parce que c’est vieux, parce qu’à votre taille une réécriture échouée d’un système central peut mettre fin à l’entreprise.

Petite entreprise. Vous n’avez pas d’équipe de maintenance dédiée et un budget serré, donc favorisez acheter et héberger plutôt que construire quoi que ce soit que vous devriez soutenir vous-même. Préférez les fournisseurs et normes ouvertes qui vous laissent partir, et gardez un enregistrement simple de quel système externe exécute quelle fonction critique et qui appeler quand il casse. Là où vous possédez du code personnalisé, assurez-vous qu’au moins deux personnes (ou un sous-traitant de confiance plus un employé) le comprennent, pour qu’un seul départ ou un contrat de support expiré ne vous laisse pas bloqué.

Grande entreprise. Votre défi est l’échelle de portefeuille : de nombreux systèmes de longue durée, de nombreuses équipes, et un personnel qui tourne sur des décennies. Standardisez la propriété au niveau de l’équipe dans un catalogue de service, mesurez le facteur bus à travers le parc, et financez la modernisation incrémentale continue plutôt que de parier sur des réécritures big bang. Gouvernez les horizons de fin de vie centralement pour qu’aucune pile critique ne vieillisse silencieusement hors du support, et exécutez chaque démantèlement comme un projet audité avec une responsabilité nommée pour terminer la mise hors service.

Gouvernement. La continuité d’obligation est absolue : vous ne pouvez pas arrêter de payer les prestations ou d’exploiter le contrôle du trafic aérien pendant que vous refactorisez, et les échecs sont publics et conséquents. Les règles de marchés publics vous poussent vers les normes ouvertes, la portabilité de données, et les interfaces documentées pour que les futurs mainteneurs et futurs fournisseurs aient une chance. Financez une formation de succession délibérée pour les technologies plus anciennes que le marché du travail ne fournit plus, préservez les enregistrements de systèmes retirés pour respecter la rétention statutaire, et traitez la fiabilité soutenue des services citoyens comme la mission responsable plutôt que la surcharge.

Exemples

Jeune pousse. Une jeune pousse de cinq personnes a déjà un système qu’elle ne peut pas se permettre de perdre : le service de facturation qu’un fondateur a écrit le premier mois et qui exécute maintenant chaque frais client. Seul ce fondateur le comprend, donc l’équipe traite le facteur bus comme un vrai risque plutôt qu’un compliment. Ils jument un second ingénieur à travers un cycle de facturation complet, écrivent un court enregistrement de décision d’architecture expliquant pourquoi la logique de nouvelle tentative étrange existe, et gardent un livre d’exécution à côté du code qu’ils exercent réellement pendant un incident. Ils résistent à le réécrire juste parce qu’il est vieux et peu glamoureux, et l’améliorent à la place par petits pas réversibles, pour que le service qui garde l’entreprise vivante soit compris par plus d’une tête.

Grande entreprise. Un grand assureur exploite un système d’administration de police d’abord écrit il y a des décennies et encore central à son affaire. Plutôt que de tenter une réécriture entière risquée, il a modularisé le système derrière des interfaces bien définies et remplace maintenant un composant à la fois, chaque changement petit et réversible. Chaque fonction critique a au moins trois personnes qui peuvent l’effectuer. L’astreinte est partagée. Les enregistrements de décision d’architecture capturent pourquoi le système fonctionne comme il le fait. Un cours interne sélectionné amène de nouveaux ingénieurs à la compétence sur la pile héritée, et les experts partants chevauchent avec les successeurs pour que la connaissance tacite se transfère en faisant.

Gouvernement. Une agence nationale de sécurité sociale exploite des systèmes de paiement de prestations qui fonctionnent depuis plus de trente ans et ne peuvent pas s’arrêter. Elle enregistre une propriété d’équipe explicite dans un catalogue de service. Elle finance la maintenance continue plutôt que de geler les systèmes. Elle forme délibérément des successeurs aux technologies plus anciennes, parce que le marché du travail ne les fournira pas. Quand elle retire un sous-système obsolète, elle exécute le démantèlement comme un projet géré : cartographiant chaque consommateur, fournissant un soutien de migration, préservant les enregistrements pour respecter les règles de rétention légale, et assignant une responsabilité pour terminer réellement la mise hors service, pour qu’aucun système zombie ne persiste.

Argumentaire économique : motivations, retour sur investissement et coût total de possession

Le retour sur le soutien des systèmes de longue durée vient d’éviter les deux modes d’échec catastrophiques qui dominent leur coût total de possession. Le premier est la crise soudaine : une personne clé part, un composant non supporté est violé, ou un système orphelin échoue sans personne qui le comprend. Le second est le mégaprojet échoué : une réécriture entière précipitée qui dépasse, sous-livre, ou s’effondre. Les deux sont énormément coûteux, et les deux sont largement évitables par une intendance stable. Le coût d’un seul échec de réécriture évité, ou d’une seule panne prolongée évitée d’un service citoyen critique, dépasse habituellement des années d’investissement de maintenance soutenu.

Le coût d’adoption est continu et peu glamoureux : financer la maintenance qui ne produit aucune nouvelle fonctionnalité, payer pour la formation croisée et le temps de documentation qui réduit la sortie à court terme, et investir dans la modernisation incrémentale qui ne fait jamais les gros titres. Le coût de ne pas adopter est différé et plus grand : risque croissant à mesure que la pile vieillit, exposition de personne clé qui gonfle, et éventuellement un remplacement forcé, à haut risque, coûteux sous des conditions d’urgence. Quand vous faites valoir le dossier auprès de la direction, recadrez la maintenance de « centre de coût » à « gestion de risque pour des systèmes que l’organisation ne peut pas se permettre de perdre ». Présentez le coût total de possession à travers la vie multi-décennale complète (incluant le soutien et la mise hors service éventuelle) plutôt que seulement la construction. Et insistez sur ceci : pour les systèmes orientés citoyen et client, la fiabilité soutenue n’est pas une surcharge. C’est la confiance qui est le vrai produit.

Anti-patterns et pièges

Le mainteneur héros. Une personne irremplaçable qui comprend le système ; son départ est un événement existentiel.
Geler et oublier. Déclarer un système critique « terminé », arrêter la maintenance, et regarder sa pile vieillir vers la non-maintenabilité.
La réécriture condamnée. Parier l’organisation sur un remplacement entier qui jette la connaissance encodée et échoue ou dépasse habituellement.
Les systèmes orphelins. Du logiciel critique sans propriétaire actuel, remarqué seulement quand il casse.
Le théâtre de documentation. Des volumes de documents qui sont périmés, non exercés, et auxquels personne ne fait confiance.
La course en parallèle éternelle. Les anciens et nouveaux systèmes fonctionnant côte à côte indéfiniment parce que personne n’est responsable de l’arrêt.
La perte de connaissance tacite. Laisser les experts partir sans chevauchement, pour que le ressenti pour le système s’évapore.
Trop effrayant pour toucher. Un système si mal compris que tout changement est craint, ce qui garantit sa décomposition.

Modèle de maturité

Niveau 1 : Initier. Le soutien est ad hoc et réactif. Les systèmes dépendent de héros individuels, la propriété est souvenue plutôt qu’assignée, et la connaissance vit non documentée dans quelques têtes. Les anciens systèmes sont gelés jusqu’à ce qu’ils cassent, les piles vieillissantes dérivent vers la fin de vie inaperçues, et les mises hors service sont annoncées mais jamais terminées.

Niveau 2 : Développer. Des pratiques de base apparaissent mais varient équipe par équipe. La propriété est écrite pour les systèmes majeurs les plus évidents, certains livres d’exécution et documentation existent, et quelques fonctions critiques ont une seconde personne capable. La maintenance est financée mais réactive, la formation croisée se produit quand quelqu’un s’en souvient, et il n’y a pas de façon partagée de faire tout cela à travers l’organisation.

Niveau 3 : Standardiser. Les pratiques d’intendance sont documentées et appliquées à l’échelle de l’organisation. La propriété au niveau de l’équipe est enregistrée dans un catalogue de service et survit aux réorganisations. L’atténuation du facteur bus à travers la rotation et la formation croisée est une règle permanente, les enregistrements de décision d’architecture et les livres d’exécution exercés sont attendus, la modernisation est incrémentale par politique, et chaque démantèlement fonctionne comme un projet géré avec une responsabilité nommée pour terminer la mise hors service.

Niveau 4 : Gérer. Le soutien est mesuré et contrôlé avec des données contre des référentiels. Vous suivez le facteur bus par système critique, le compte de personnes qui peuvent le changer en sécurité, l’âge de chaque technologie centrale contre sa date de fin de vie, la part du parc sous maintenance continue contre différée, et le nombre de courses parallèles calées et de mises hors service à moitié terminées. Ces métriques portent des seuils qui déclenchent une action : un système qui tombe sous le plancher de facteur bus ou traverse un horizon de fin de support obtient une remédiation financée, et la santé d’intendance est rapportée à la direction aux côtés de la livraison.

Niveau 5 : Orchestrer. L’intendance est continuellement améliorée et intégrée à travers l’organisation. Aucun système critique n’est un point unique de défaillance humaine, le transfert de connaissance incluant la connaissance tacite à travers le chevauchement est routinier, et les systèmes évoluent par petits pas réversibles pour qu’aucun ne vieillisse hors du support. La propriété, le suivi de fin de vie, la succession, et la planification de démantèlement sont tissés dans la planification de portefeuille et de risque, le parc est rééquilibré à mesure que les technologies et obligations changent, et les systèmes multi-décennaux sont soutenus tout en préservant la confiance des gens qui en dépendent.

Pistes de réflexion

Comment mesurez-vous le facteur bus de façon significative, et quelle cible est correcte pour différents niveaux de criticité ?
Quand une modernisation incrémentale est-elle véritablement infaisable, faisant d’une réécriture le moindre risque ?
Comment financez-vous et récompensez-vous le travail de maintenance pour que l’intendance soit un chemin de carrière respecté, pas une impasse ?
Quelle est la bonne façon de préserver la connaissance tacite quand le dernier expert est sur le point de partir à la retraite et qu’aucun chevauchement n’est possible ?
Combien de temps devriez-vous retenir la capacité de répondre à des questions sur un système retiré, et qui paie pour cela ?
Où dans votre parc la stabilité est-elle la valeur et la nouveauté un passif, et comment gardez-vous ce jugement honnête dans le temps ?

Points clés à retenir

La plupart du logiciel important est vieux et de longue durée ; le soutenir à travers des décennies et des générations de personnel est une discipline de premier ordre.
Chaque système critique a besoin d’une propriété actuelle au niveau de l’équipe ; les systèmes critiques orphelins sont des urgences latentes.
Réduisez le facteur bus délibérément (aucune tâche critique ne devrait avoir exactement une personne capable) et transférez la connaissance tacite à travers le chevauchement, pas seulement des documents.
Gardez les systèmes de longue durée continuellement et incrémentalement maintenus ; les geler et parier sur des réécritures entières sont tous deux des modes d’échec.
Planifiez les fins comme des projets gérés avec un achèvement responsable, préservant les données et enregistrements pour respecter les obligations.
Pour les systèmes orientés citoyen et client, la fiabilité et l’équité soutenues sont la mission, et la maintenance est de la gestion de risque pour ce que vous ne pouvez pas vous permettre de perdre.

Références et lectures complémentaires

Michael Feathers, Working Effectively with Legacy Code
Titus Winters, Tom Manshreck, et Hyrum Wright, Software Engineering at Google
Frederick P. Brooks Jr., The Mythical Man-Month
Nat Pryce et Steve Freeman, Growing Object-Oriented Software, Guided by Tests
Sam Newman, Monolith to Microservices
Martin Fowler, Refactoring et écrits sur le motif du figuier étrangleur
Betsy Beyer et al., Site Reliability Engineering et The Site Reliability Workbook (Google)
Diomidis Spinellis, Code Reading: The Open Source Perspective
U.S. Government Accountability Office, rapports sur la modernisation informatique héritée fédérale