Quatre chiffres décident quand réécrire un logiciel ancien

La réécriture d'un système ancien se justifie lorsque le coût et le risque de le modifier dépassent ceux de son remplacement. L'âge, le langage et les préférences d'architecture ne répondent pas à cette question. Quatre mesures le font : le taux d'échec des changements, la part de l'équipe capable de modifier le code sans danger, la part non prise en charge de l'environnement d'exécution et le coût d'un seul incident grave.

J'ai vu des équipes autoriser une réécriture parce qu'un framework semblait vieux, puis découvrir que l'ancienne application changeait deux fois par an sans poser de problème. J'en ai vu d'autres défendre « l'amélioration progressive » alors qu'un seul mainteneur portait un système de production sur un environnement abandonné. Ces deux décisions reposaient sur une intuition déguisée en raisonnement technique. Placez les quatre chiffres sur une page et il devient bien plus difficile de truquer le débat.

Une décision de réécriture exige des mesures, pas un âge limite

Aucun âge ne transforme automatiquement un logiciel en candidat à la réécriture. Un service de quinze ans doté d'interfaces stables, de dépendances prises en charge, de bons tests et de plusieurs mainteneurs compétents peut coûter moins cher à conserver qu'un service de trois ans qui tombe à chaque livraison. L'âge indique où regarder, mais ne décide rien.

Il en va de même pour le langage. COBOL, RPG, VB6, Delphi ou une ancienne version de PHP peuvent compliquer le recrutement et l'assistance, mais le nom d'un langage ne quantifie aucun des deux. Un traitement COBOL bien compris, qui transforme chaque nuit un fichier fixe, peut mériter dix années de plus. Un petit service JavaScript que seul un prestataire comprend peut déjà constituer un risque d'exploitation.

Choisissez une période de mesure qui comprend les livraisons ordinaires et au moins une phase d'activité exigeante. Un trimestre convient souvent aux équipes qui livrent régulièrement. Un système qui évolue lentement peut demander plus de temps, mais n'attendez pas éternellement des données parfaites. Notez l'incertitude à côté de chaque chiffre et améliorez la mesure au fil du temps.

Utilisez la même unité d'analyse pour les quatre mesures. Décidez si vous évaluez une application, un service déployable ou un groupe étroitement couplé qui doit évoluer ensemble. Mesurer les échecs de tout un portefeuille et les mainteneurs d'un seul dépôt produit un tableau soigné mais vide de sens.

Les quatre chiffres répondent à des questions différentes :

• L'équipe peut-elle modifier le système sans casser la production ?
• Combien de personnes peuvent effectuer ce changement sans supervision ?
• Quelle part du logiciel exécuté ne reçoit plus de correctifs de ses responsables ?
• Que perd l'entreprise lors d'un incident grave ?

Aucun seuil n'est universel. Fixez une limite adaptée à votre tolérance au risque, puis écrivez l'action qui suit son franchissement. La valeur vient de l'application de la même règle avant une panne, quand personne ne peut la tordre pour soutenir une conclusion déjà choisie.

Le taux d'échec révèle la taxe sur chaque livraison

Le taux d'échec des changements indique la fraction des changements en production qui demandent une correction parce qu'ils ont dégradé le service, provoqué une panne, un retour arrière ou un correctif urgent. DORA emploie cette notion pour mesurer la performance de livraison logicielle. Je garderais une définition stricte : comptez les échecs causés par un changement, pas tous les incidents survenus près d'un déploiement.

Définissez ce qui constitue un changement de production avant le calcul. Incluez les déploiements applicatifs, migrations de base, versions de configuration, modifications de planificateur et d'infrastructure si l'équipe les dirige comme un même processus. Ne comptez pas une simple nouvelle tentative comme un second échec. Ne transformez pas non plus dix commits d'urgence après une mauvaise livraison en dix échecs indépendants.

Le calcul de base est simple :

change_failure_rate = failed_production_changes / total_production_changes

La classification est la partie difficile. Pour chaque changement raté, notez le changement déclencheur, l'effet sur les clients, l'action de reprise et si le défaut venait du code, des données, de la configuration ou d'une interaction inconnue. Une étiquette de ticket comme change-failure suffit si tous l'appliquent de façon constante. Examinez chaque mois les cas contestés avec développement et exploitation autour de la même table.

Ne comparez pas les taux bruts de systèmes aux rythmes de livraison radicalement différents. Une application peut livrer cent petites modifications tandis qu'une autre publie une version groupée. Associez le taux au volume de changements et au temps médian de reprise. Un taux de 10 % sur dix indicateurs fonctionnels réversibles n'a pas le même risque commercial que 10 % sur des versions trimestrielles de base de données dont la restauration prend six heures.

La tendance compte davantage qu'une mesure isolée. Si le taux baisse après l'amélioration des tests, de l'observation et la réduction des livraisons, les corrections rendent le contrôle à l'équipe. S'il reste élevé après deux ou trois tentatives ciblées, l'architecture combat peut-être la méthode de livraison. Cherchez les causes répétées : état mutable partagé, ordre des traitements non documenté, contrats cachés dans la base et étapes de déploiement impossibles à répéter. Ces schémas renchérissent chaque future fonction.

Ne récompensez pas une équipe qui évite les changements. Un système sans déploiement a un taux indéfini ou faussement parfait. Suivez les demandes repoussées parce que la mise en production semblait trop risquée. Lorsque les changements métier s'accumulent par peur de toucher la production, l'absence d'échec prouve la paralysie, pas la santé.

La responsabilité réelle est plus rare que l'accès au dépôt

La part de modification sûre correspond à la proportion de l'équipe concernée qui peut indépendamment effectuer, relire, déployer et récupérer une modification significative du système. L'accès au dépôt ne compte pas. Savoir modifier un fichier pendant que l'unique expert dicte chaque étape ne compte pas non plus.

Définissez une modification significative à partir du travail que le système reçoit réellement. Il peut s'agir d'ajouter un champ à travers la base, le service et l'interface, de changer un calcul aux conséquences financières, ou de modifier un traitement nocturne sans casser sa reprise. La tâche doit franchir les frontières où le savoir disparaît habituellement.

Évaluez chaque ingénieur sur quatre capacités :

• Expliquer le chemin d'exécution touché et ses dépendances.
• Réaliser et tester le changement sans copier un précédent incompris.
• Le livrer par le véritable processus de production.
• Diagnostiquer une panne et rétablir le service sans attendre l'oracle du système.

Ne comptez une personne que si des preuves récentes couvrent les quatre points. Travailler en binôme aide à apprendre, mais ne prouve pas une responsabilité autonome. Les revues, la participation aux incidents et une modification réussie en production valent mieux qu'une autoévaluation.

Calculez ensuite :

safe_touch_share = independent_safe_maintainers / relevant_engineers

Notez aussi le nombre absolu. Une part de 50 % paraît saine jusqu'à ce qu'elle signifie une personne sur deux. À l'inverse, quatre mainteneurs capables dans une équipe de vingt peuvent suffire pour une application interne stable, à condition que les astreintes et congés ne retirent pas les quatre en même temps.

Cette mesure révèle une distinction souvent effacée : la disponibilité d'une documentation n'est pas une connaissance opérationnelle. Un manuel de mille pages peut décrire écrans et tables tout en omettant pourquoi le règlement doit précéder le rapprochement, quels enregistrements les opérateurs réparent à la main ou comment reprendre un traitement sans comptabiliser deux fois. Testez le document en demandant à un nouveau mainteneur de l'utiliser sous supervision. Ses questions font partie de la spécification manquante.

Une part en baisse est souvent le premier signal de réécriture car elle cache une échéance. Un départ en retraite, une démission ou la fin d'un contrat peut rendre un système difficile impossible à modifier du jour au lendemain. Si le transfert de connaissances augmente la part et que les personnes formées continuent à livrer six mois plus tard, les corrections gardent un argument. Si chaque transfert ramène le travail vers le même expert, cessez d'appeler cela une formation.

La part d'exécution abandonnée mesure l'exposition, pas la honte

La part non prise en charge est la proportion de la pile de production qui ne reçoit plus de correctifs de sécurité ou de fonctionnement du fournisseur ou du projet responsable. Elle dépasse le langage applicatif. Comptez les systèmes d'exploitation, bases de données, serveurs applicatifs, environnements d'exécution, frameworks majeurs, pilotes et intergiciels indispensables.

Inventoriez ce qui tourne vraiment, pas ce que prétend le schéma d'architecture. Extrayez les versions des hôtes, images de conteneur, fichiers de verrouillage, définitions de tâches et requêtes de base. Sur un grand système ou une machine intermédiaire, incluez compilateurs, moniteurs de transactions, planificateurs et composants fournisseurs du chemin d'exécution. Conservez la source de chaque date de support pour éviter que les rumeurs d'achat deviennent une politique.

Un calcul pondéré utile est :

unsupported_runtime_share = sum(weight_of_unsupported_components) / sum(weight_of_all_components)

Pondérez selon l'exposition et le rôle métier. Un serveur applicatif public abandonné mérite plus de poids qu'un convertisseur de rapports isolé utilisé une fois par mois. Gardez une pondération assez simple pour qu'un autre ingénieur la reproduise. Si un comité prend une heure pour expliquer le poids de 7,3 d'un composant, cette précision est fictive.

Non pris en charge ne veut pas dire compromis, et pris en charge ne veut pas dire sûr. Le premier signifie que le responsable ne fournit plus de voie normale de correction. L'équipe peut compenser par l'isolation, des correctifs virtuels, des contrôles d'entrée stricts ou un contrat de support prolongé. Inscrivez chaque contrôle à côté du composant et vérifiez qu'il couvre vraiment chaque point d'entrée.

Repérez le noyau abandonné caché sous des bords actuels. Un navigateur, un proxy inverse et une base récents ne sauvent pas une logique métier qui exige un environnement délaissé. Certaines équipes mettent à jour tout ce qui entoure le vieux noyau puis annoncent peu de composants obsolètes. La pondération par importance d'exécution empêche ce tour comptable.

Les corrections restent raisonnables lorsque les composants abandonnés sont isolés, stables, remplaçables séparément et couverts par des contrôles peu coûteux. Elles deviennent difficiles à défendre si un composant accepte des entrées non fiables, bloque les mises à niveau du système ou impose toute une chaîne de déploiement obsolète. L'exposition s'accumule alors : chaque mise à niveau voisine doit s'adapter à la pièce la plus ancienne.

Le coût d'un incident transforme le risque technique en limite métier

Le coût d'un incident grave couvre toute la perte commerciale de la détection jusqu'au rétablissement et à la correction, pas seulement la facture du cloud ou les heures supplémentaires. Utilisez un incident réel si possible. À défaut, construisez un scénario avec finances, exploitation, sécurité et responsable métier, puis marquez chaque hypothèse.

Calculez le coût par catégories vérifiables :

incident_cost = lost_margin
              + staff_hours * loaded_hourly_cost
              + customer_remediation
              + contractual_or_regulatory_cost
              + data_reconciliation
              + delayed_business_events

Utilisez la marge perdue plutôt que la valeur brute des transactions, sauf si celles-ci disparaissent définitivement. Séparez le revenu retardé du revenu perdu. Comptez le travail manuel de l'exploitation, des finances, du support, du développement et de la direction. Incluez les jours suivant le retour du service, consacrés à rapprocher les données, corriger les doublons, répondre aux clients et préparer les avis obligatoires.

Ne multipliez pas un chiffre horaire effrayant par la panne la plus longue imaginable. Définissez précisément l'incident grave, par exemple quatre heures d'arrêt de prise de commandes suivies d'une journée de rapprochement, ou un calcul de prix erroné qui atteint les clients. Documentez volume, marge, coûts du personnel, clauses et hypothèses de reprise. Les finances doivent pouvoir contester le modèle ligne par ligne.

Utilisez deux coûts si le système connaît des modes de panne distincts. Un problème de disponibilité et un défaut silencieux d'intégrité ont rarement la même forme. Le second peut paraître peu coûteux pendant la panne, car personne ne le détecte, puis coûter bien davantage lors de la reconstruction. Une moyenne masque cette différence.

Le coût modifie l'argument de réécriture car il fixe le montant raisonnable pour réduire l'exposition. Un système fragile qui gère un petit processus interne peut rester corrigé. Un système tout aussi fragile qui comptabilise des écritures ou dirige les mouvements d'une usine mérite une tolérance plus basse sur les trois autres mesures.

Ne transformez pas le coût en tour de magie d'espérance mathématique sans données de fréquence crédibles. Multiplier une probabilité annuelle devinée par une conséquence modélisée produit une jolie somme avec deux entrées faibles. Laissez visibles preuves de fréquence, de conséquence et incertitude. La direction peut décider sans prétendre faire de l'actuariat.

Placez les quatre chiffres sur une fiche de décision

Une fiche doit afficher les valeurs actuelles, leur tendance, le niveau de confiance, une limite convenue et l'action liée à son franchissement. Une page suffit. Elle force les arbitrages explicites, elle ne calcule pas une réponse à laquelle la direction devrait obéir.

Utilisez un tableau de ce type et remplacez les limites d'exemple :

Ces valeurs illustrent la méthode, elles ne constituent pas des références. Une interface de facturation hospitalière, une imprimante d'étiquettes d'entrepôt et un catalogue public demandent des limites différentes. Les responsables doivent choisir les limites avant le prochain incident et garder les preuves de chaque valeur.

Ne réduisez pas trop vite les quatre mesures à un score pondéré. Un score de 62 cache des pannes fréquentes et bon marché ou une dépendance abandonnée catastrophique. Gardez les quatre axes visibles. Si la direction veut un statut, utilisez trois états :

• Continuer les corrections tant que les mesures restent dans leurs limites et progressent.
• Confiner et préparer lorsqu'une mesure franchit sa limite ou que plusieurs se dégradent.
• Réécrire lorsque l'exposition dépasse la limite convenue et que les corrections crédibles ont échoué.

Fixez une date de revue et nommez le responsable de chaque entrée. Les échecs viennent des données de déploiement et d'incident. Les preuves de responsabilité appartiennent au responsable technique. Le support des environnements demande une revue de plateforme ou de sécurité. Les finances et le métier doivent approuver les conséquences.

La fiche empêche aussi l'élargissement du périmètre. Si seul un planificateur crée l'exposition, remplacez ce composant au lieu de condamner tout le patrimoine. Si la responsabilité est la seule faiblesse, rotation et documentation peuvent suffire. Une réécriture mérite approbation lorsque les mesures désignent une frontière impossible à réparer économiquement sur place.

Les corrections gagnent lorsque le risque est borné et réversible

Continuer à corriger est juste si les changements échouent rarement, plusieurs personnes savent les gérer, les composants abandonnés sont réellement confinés et un incident resterait tolérable. Une réécriture consomme une attention qui pourrait améliorer les produits visibles par les clients. Ne remplacez pas un logiciel stable pour satisfaire un schéma d'architecture.

Plusieurs situations favorisent nettement les corrections. Le système peut approcher d'un retrait planifié avec la fermeture d'une activité. Son comportement peut être fixé par règlement ou contrat, avec peu de changements prévus. Un fournisseur peut offrir une mise à niveau prise en charge qui retire l'environnement exposé sans toucher à la logique. L'application peut aussi se trouver derrière une interface étroite et contrôlée, sans entrée non fiable, avec une reprise testée.

Les corrections exigent un périmètre et une condition de sortie. Financez la mise à jour des dépendances, les tests de caractérisation, l'automatisation des déploiements, l'observation et le transfert de savoir. Mesurez de nouveau. Si le taux d'échec baisse et la responsabilité augmente, le plan fonctionne. Si chaque cycle reconstruit le même déploiement fragile ou protège un environnement qui bloque tout le reste, le programme est devenu un retard coûteux.

Je conteste la règle populaire selon laquelle tout vieux monolithe doit d'abord être découpé en microservices. Le conseil semble progressif, donc plus sûr qu'une réécriture. En pratique, extraire des services d'un code dont personne ne sait définir le comportement distribue souvent l'incertitude sur un réseau. Vous ajoutez pannes partielles, interfaces versionnées et charge d'exploitation avant de prouver la parité. Capturez d'abord le comportement à la frontière du système, puis choisissez des limites qui suivent responsabilités métier et propriété des données.

Le remplacement sélectif est une autre bonne option. Gardez un calcul ou un traitement stable et remplacez l'interface abandonnée. Placez une dépendance de base derrière un service pris en charge. Supprimez les rapports inutilisés avant de les traduire. Recalculez les quatre mesures sur le périmètre restant après chaque retrait, car un noyau plus petit peut devenir assez peu coûteux pour rester confiné.

Ne confondez pas correction et inaction. Conserver le système engage un travail précis : contrats de support, tests des contrôles, exercices de reprise, couverture du personnel et réévaluation planifiée. Si personne ne finance ces éléments, l'organisation n'a pas choisi de corriger. Elle a choisi un déclin sans gestion.

Une réécriture préserve le comportement avant de changer l'architecture

Une réécriture défendable capture le comportement observable, exécute ancienne et nouvelle versions sur les mêmes cas et ne change l'architecture que lorsque les preuves le permettent. Une traduction ligne à ligne conserve la structure accidentelle et peut reproduire les défauts sans le contexte opérationnel qui permettait de les maîtriser.

Commencez par des preuves proches de la production. Enregistrez requêtes et réponses si les règles l'autorisent, capturez entrées et sorties des traitements, conservez des erreurs représentatives et repérez les effets secondaires comme fichiers, messages, écritures en base et invites opérateur. Masquez les valeurs sensibles, mais gardez distributions, ordre et cas malformés qui exercent les vraies branches.

Construisez un banc de parité capable d'envoyer un cas aux deux systèmes et de comparer des résultats normalisés. Normalisez explicitement les horodatages, identifiants générés, ordres sans signification et autres champs non déterministes. Ne cachez jamais une différence avec un filtre de texte général. Chaque règle doit expliquer pourquoi l'écart n'a pas de sens.

Pour un comportement avec état, comparez les transitions plutôt que l'écran final. Initialisez les deux systèmes avec la même base, exécutez l'action puis comparez lignes modifiées, messages, fichiers et valeurs renvoyées. Pour un traitement, testez la fin normale, la reprise après interruption, l'entrée dupliquée, l'entrée tardive et la panne partielle en aval. Les opérateurs dépendent souvent de ces comportements plus que ne le pensent les développeurs.

L'architecture peut alors changer sans pari. Un patrimoine COBOL et JCL peut devenir des services Go et une base Postgres, un noyau numérique peut justifier Rust, un client de bureau peut passer à TypeScript. Ce sont des choix de conception, pas des objectifs. L'objectif est un comportement métier équivalent dans un modèle que l'équipe actuelle sait exploiter.

CodeHero lit tout l'arbre source et vérifie le système modernisé avec un banc de parité utilisant le trafic de production enregistré, au lieu de traduire les fichiers séparément. Ses projets sont livrés en moins de 30 jours, y compris dans les environnements réglementés où les modèles fournis peuvent fonctionner hors connexion dans le périmètre du client.

Traitez les écarts de parité comme des découvertes de spécification. Certains révèlent des défauts de la réécriture. D'autres exposent un ancien comportement contradictoire, une logique liée à l'environnement ou des données de production qui violent les règles supposées. Le responsable métier doit décider quelles particularités sont des contrats et lesquelles sont des bogues. Le code seul ne donne pas cette réponse.

L'approbation exige une alternative chiffrée, pas de l'enthousiasme

Une proposition de réécriture doit affronter un plan de correction entièrement chiffré et un plan de confinement entièrement chiffré. Si l'alternative est « continuer à souffrir », la comparaison est truquée. Chiffrez mises à niveau, tests, spécialistes, contrats de support, contrôles, exposition aux incidents et retards de fonctions réellement nécessaires.

Chiffrez la réécriture au-delà de l'implémentation. Incluez découverte, capture du comportement, conversion des données, fonctionnement parallèle, recette, bascule, préparation du retour, formation et retrait. Attribuez les décisions métier et la validation des données. Un remplacement techniquement terminé peut échouer si les finances ne rapprochent pas les soldes d'ouverture ou si les opérateurs ne savent pas reprendre un traitement interrompu.

Exigez des preuves pour le calendrier. Inventoriez intégrations, données, tâches planifiées, rapports, rôles, échanges de fichiers et procédures d'exploitation. Marquez chaque élément comme observé, déduit ou inconnu. L'inconnu ne bloque pas automatiquement le projet, mais quelqu'un doit décider comment le tester avant la bascule.

La porte d'approbation doit répondre clairement à cinq questions :

1. Quelle mesure a franchi la limite convenue, et quelles preuves le montrent ?
2. Quelle correction l'équipe a-t-elle tentée et comment la mesure a-t-elle réagi ?
3. Quelle frontière sera remplacée, conservée ou retirée ?
4. Comment prouver la parité et répéter un retour arrière ?
5. Quel responsable métier accepte les différences restantes et le risque de bascule ?

Si les réponses restent vagues, financez une courte phase de preuve plutôt qu'une réécriture. Elle doit produire l'inventaire d'exécution, l'évaluation des responsabilités, le modèle d'incident, le corpus comportemental et la frontière du système. Elle ne doit pas produire une présentation sur la modernité.

L'approbation doit aussi fixer des conditions d'arrêt. Si des écarts persistent dans un processus lourd de conséquences, si la conversion des données ne se rapproche pas ou si le remplacement ne respecte pas une exigence de reprise, la bascule attend. L'argent déjà dépensé ne rend pas sûr un système non vérifié.

Réexaminez la décision après chaque changement important

La décision expire dès que changent le système, l'équipe ou les conséquences métier. Recalculez les quatre mesures après une mise à jour majeure, un transfert de responsabilité, une acquisition, un déplacement du trafic, une nouvelle obligation ou un incident grave. Une fiche oubliée pendant un an devient un document ancien de plus.

Gardez les preuves proches du travail normal. Les enregistrements de déploiement doivent identifier les changements corrigés. Les revues d'incident doivent séparer les échecs causés par un changement des autres pannes et conserver les vrais coûts de travail et de rapprochement. Les compétences se prouvent par les livraisons. L'inventaire doit se mettre à jour depuis les environnements exécutés, pas par un questionnaire annuel.

Surveillez la direction autant que les seuils. Quatre mesures juste sous leur limite mais qui se dégradent ensemble justifient une préparation. Une mesure hors limite mais en amélioration rapide peut justifier un cycle de correction. Inscrivez l'exception, son propriétaire et sa date d'expiration afin qu'une tolérance temporaire ne devienne pas une politique permanente.

Les cas les plus difficiles donnent des signaux opposés. Un système peut rester stable et peu coûteux pendant un incident tandis que sa responsabilité s'effondre. Il peut compter de nombreux mainteneurs et dépendre d'un environnement public abandonné. Ne faites pas disparaître l'axe gênant dans une moyenne. Décidez si un contrôle crédible peut déplacer cette mesure avant l'échéance cachée.

La première réunion utile n'est pas un atelier de réécriture. C'est une revue où développement, exploitation, sécurité, finances et métier apportent chacun les preuves d'un chiffre. Fixez ensuite les limites et financez l'action qui leur correspond. Si les chiffres soutiennent les corrections, corrigez sans vous excuser. S'ils montrent que chaque changement sûr dépend d'un savoir qui disparaît, d'un logiciel abandonné et d'un coût d'incident intolérable, cessez de payer l'illusion qu'un correctif de plus rendra le contrôle.