Application devenue difficile à faire évoluer

En 2018, Stripe et Harris Poll ont interrogé plus de mille développeurs et plus de mille dirigeants aux États-Unis, au Royaume-Uni, en France, en Allemagne et à Singapour. Une question demandait aux développeurs combien d’heures par semaine ceux de leur entreprise perdent en maintenance, l’étude listant le code défectueux et les erreurs, le débogage, le refactoring, qui réécrit du code sans changer ce qu’il produit, et les modifications. La réponse moyenne, tous pays confondus, était de 17,3 heures. La France donnait la valeur la plus élevée relevée par l’étude, 20,9 heures. Ces heures se paient avant qu’aucune décision de refonte ne soit prise. Quand vos équipes vous disent que l’application est devenue difficile à faire évoluer, c’est ce temps-là qu’elles décrivent, sans le chiffrer. Le mot nomme un effet et laisse la cause ouverte. Quatre situations le produisent, et elles ne se corrigent ni au même endroit ni au même prix. Voici les deux mesures qui remplacent l’impression, les quatre causes avec le test qui sépare chacune des autres, et la réponse que chacune appelle.

Ce que vos équipes appellent une application difficile à faire évoluer

Le terme application legacy, que vous verrez apparaître dans les devis, désigne un outil toujours en service que plus personne ne modifie sans risque. Il décrit un état, sans rien dire de son origine. Une application peut y arriver avec une seule équipe et une longue durée de service, ou avec quelques années et plusieurs prestataires successifs. L’âge seul ne classe rien, et c’est ce qui rend la phrase difficile à instruire quand elle remonte jusqu’à vous.

Ce qu’elle recouvre se mesure pourtant, sur deux plans distincts : ce que la situation consomme aujourd’hui, et ce qu’elle fait au délai de vos projets.

Les heures de maintenance sont déjà comptées, ailleurs

La même étude de Stripe place, dans une semaine de travail moyenne de 41,1 heures, 13,5 heures consacrées à la dette technique et 3,8 heures passées sur du code défectueux. Ces valeurs sont des estimations déclarées par des développeurs à propos de leur propre entreprise, pas un relevé d’horodatage. Elles situent un ordre de grandeur, elles ne décrivent pas votre cas.

Ce qui décrit votre cas est le relevé de votre propre exercice. Une comparaison de refonte oppose le coût du chantier à celui du statu quo, et le statu quo a un coût : la maintenance corrective se facture, elle occupe des journées, et ces journées ne produisent aucune évolution. Elles sortent du même budget que celles qui en produiraient. Votre prestataire actuel dispose de ses propres relevés sur les douze derniers mois. Demandez-lui, avant d’ouvrir le sujet du chantier, comment ses interventions de l’année se répartissent entre les corrections et les ajouts. Gardez à l’esprit qu’il s’agit du même prestataire qui chiffrera ensuite le chantier éventuel, ce qui ne rend pas sa réponse fausse mais mérite d’être su avant de la lire.

Mesurer la difficulté plutôt que la décrire

Le programme de recherche DORA publie cinq mesures de performance de livraison logicielle, réparties entre le débit et l’instabilité. Deux d’entre elles répondent à la question qui vous occupe.

La première, le délai de mise en service d’un changement, se définit comme le temps qu’un changement met à passer de son enregistrement dans le gestionnaire de versions à sa mise en production. Retenez où démarre ce compteur : au moment où le développeur enregistre son travail, pas au moment où vous validez la demande. Le délai de mise en service que vos équipes subissent commence bien plus tôt, et il faut compter les deux durées séparément pour savoir laquelle s’allonge.

La seconde, le taux d’échec des changements, se définit comme la part des mises en production qui exigent une intervention immédiate, un retour arrière ou un correctif d’urgence. Celle-là se relève sans aucun outil, à partir de votre historique de tickets. Une régression, un changement qui en abîme un autre, en est une cause parmi d’autres, aux côtés d’une erreur de configuration ou d’une indisponibilité. Ces deux mesures se lisent ensemble : un délai qui s’allonge pendant que le taux reste stable et un délai qui s’allonge pendant que le taux monte ne désignent pas le même problème.

Quatre situations produisent ce même constat

Ces quatre situations ne s’excluent pas. Quand plusieurs sont présentes, c’est celle qui domine qui décide du chantier, et le test attaché à chacune sert à la désigner. Aucun de ces tests ne demande d’ouvrir le code.

Le socle technique ne se met plus à jour

La sixième catégorie du classement OWASP Top 10 publié en 2021 porte sur les composants vulnérables et obsolètes. Elle liste six conditions qui exposent une application, et deux d’entre elles décrivent le socle dont il est question ici : « le logiciel est vulnérable, non supporté ou obsolète », et « les développeurs ne testent pas la compatibilité des bibliothèques mises à jour, mises à niveau ou corrigées ». OWASP parle de risque de sécurité. Le même état produit un second effet, sur vos délais, et c’est celui-là qui vous remonte.

Le mécanisme tient dans la seconde condition. Votre application s’appuie sur des briques logicielles écrites par d’autres, et ces briques dépendent entre elles. Monter la version de l’une réclame de vérifier que les autres suivent. Quand cette vérification n’existe pas, personne ne monte rien, et les dépendances obsolètes s’accumulent sans que rien ne se voie. Vient le jour où une correction de sécurité réclame une version que votre socle ne supporte pas, et cette correction devient un projet.

Vous reconnaissez ce cas au contenu des devis : une demande d’évolution modeste revient chiffrée avec une remise à niveau technique attachée, et la part technique pèse plus lourd que la part fonctionnelle. Le sujet touche aussi vos accès, et un relevé des accès que personne n’a prévus dit lesquels de ces retards vous exposent réellement.

Les règles de calcul ne sont écrites nulle part

Martin Fowler décrit le remplacement progressif d’un système en service et pose au passage la difficulté centrale de l’exercice : « les remplacements semblent faciles à spécifier, mais il est souvent difficile d’établir le détail du comportement existant ».

Dans une application d’entreprise, ce comportement existant s’appelle vos règles métier non documentées. Un barème de remise arrêté un jour par quelqu’un, un calcul de commission qui traite différemment deux catégories de clients, une relance déclenchée à un délai que personne ne sait justifier : ces règles vivent dans le code, et leur justification vit dans la mémoire de quelques personnes. Toute modification voisine oblige d’abord à reconstituer ce qui existe, et ce travail recommence à la demande suivante.

Choisissez une règle de calcul et demandez à votre prestataire pourquoi le montant sort ainsi. Comptez ensuite deux choses : combien de personnes il a fallu interroger, et combien de jours la réponse a mis à venir. Quand la réponse n’arrive pas, le chantier commence par reconstituer ce que fait l’outil quand plus personne ne sait le dire, et cette étape existe qu’il y ait refonte ensuite ou non.

Chaque correction en casse une autre

Une application se vérifie de deux façons. Une personne rejoue à la main les cas qu’elle connaît, ou des contrôles écrits une fois rejouent seuls, à chaque changement, les cas pour lesquels ils ont été écrits. Sans ces contrôles, l’étendue de la vérification suit le temps disponible, et le temps disponible suit la date de livraison promise.

La conséquence se lit dans le comportement de l’équipe avant de se lire dans les incidents. Une équipe qui ne peut pas vérifier vite a une seule marge de manœuvre, réduire ce qu’elle change à la fois. Elle refuse les changements groupés, découpe chaque demande, et rallonge chaque livraison d’une phase de contrôle manuel. Vos évolutions ne sont alors pas bloquées, elles deviennent lentes et chères, ce qui vous remonte dans les mêmes termes.

Cette cause est la seule des quatre dont le test se compte plutôt qu’il ne se lit : sur vos dernières mises en service, celles qui ont été suivies d’une correction urgente. La liste de la section suivante le produit en même temps que le reste. Ce nombre se compare à lui-même d’une période sur l’autre, et il ne se compare pas à celui d’une autre entreprise, parce que ce que vous appelez une mise en service ne recouvre pas la même chose ailleurs.

L’application porte un métier qu’elle n’a jamais eu à porter

Les trois premières causes portent sur la façon dont l’application est construite. La quatrième porte sur ce qu’elle a à couvrir. Une application est découpée une fois, au moment où elle se spécifie, et ce découpage fixe ce qu’un écran peut recevoir et ce qui relève d’un autre écran. Quand l’activité que l’outil porte se déplace, le découpage, lui, ne bouge pas.

Le signe se lit dans le chiffrage plutôt que dans le motif de refus. Une demande arrêtée pour une raison technique reçoit un motif technique, la version en cause, la reprise à faire, le risque de casse, et ce motif désigne les trois causes précédentes. Une demande arrêtée parce que le périmètre ne tient plus reçoit autre chose : un chiffrage qui déborde la demande, plusieurs écrans et parfois plusieurs services engagés pour un besoin qui n’en visait qu’un.

Le test tient donc en une lecture. Reprenez la dernière évolution qu’on vous a refusée ou chiffrée trop cher, et comparez ce qu’elle demandait à ce que le devis touchait. Un écart de périmètre entre les deux désigne cette quatrième cause. Quand l’outil sert plusieurs services à la fois, le chantier consiste d’abord à séparer les domaines de l’outil et désigner un arbitre pour chacun.

Trois des quatre causes ont une réponse moins lourde qu’une refonte

Nommer la cause dominante change le chantier qu’on vous chiffre, et il vaut de le faire avant de demander un devis, parce qu’un chantier mal nommé se paie deux fois, une fois pour ce qu’il fait et une seconde pour ce qu’il n’a pas traité.

Sur un socle qui ne se met plus à jour, la réponse est une modernisation par lots qui ne redéfinit rien de ce que fait l’outil. Vos utilisateurs retrouvent les mêmes écrans et les mêmes calculs, le travail porte sur les briques qui les font tourner. Ce chantier consiste à reconstruire les fondations de l’outil sans jamais couper l’accès de ceux qui s’en servent au quotidien, un lot après l’autre. Refondre l’application entière pour cette seule raison vous ferait payer une redéfinition fonctionnelle dont vous n’avez pas besoin.

Sur des règles non écrites, aucune refonte ne règle quoi que ce soit par elle-même, elle en dépend. Un projet lancé sans ce travail préalable reproduit les règles à l’aveugle ou les perd, et l’écart se découvre après la bascule, sur des montants. La reconstitution se facture donc de toute façon, et vous avez intérêt à la traiter séparément pour en garder le résultat, qu’une refonte suive ou non.

Sur les régressions, l’écriture des contrôles automatiques se mène sur l’application actuelle, sans rien reconstruire. Ce chantier a une seconde utilité : les mêmes contrôles servent ensuite de référence le jour où une nouvelle version doit rendre les mêmes résultats que l’ancienne.

Reste la quatrième, la seule des quatre où la reconstruction est la réponse, et la seule où la question posée n’est plus technique mais porte sur ce que l’outil doit couvrir. Quand le périmètre ne correspond plus à votre activité, refaire l’application à l’identique sur une base neuve reproduit le problème avec une facture en plus. Un cas intermédiaire existe entre cette situation et les trois précédentes. Quand seules quelques fonctions bloquent et que le reste tient, le chantier se traite par une reprise par lots limitée aux fonctions que l’équipe évite de rouvrir, sans engager le reste.

Deux mots reviennent dans ces discussions et ne désignent pas le même chantier. Le refactoring appartient aux trois premières réponses. La réécriture complète, qui refait l’outil, appartient à la quatrième. Les confondre dans une discussion de devis suffit à faire chiffrer le mauvais chantier.

Reprendre vos dix dernières demandes d’évolution

Ce classement se fait sur vos propres dossiers, avec ce que vous avez déjà. Sortez les dix dernières demandes d’évolution formulées sur l’application, en gardant celles qui ont abouti comme celles qui ont été abandonnées.

Pour chacune, notez quatre choses. La date à laquelle vous avez validé la demande. La date de sa mise en service, ou la mention « abandonnée ». Le motif donné, dans les mots de celui qui l’a donné, pour les demandes abandonnées ou rechiffrées à la hausse. Et, pour celles qui ont abouti, si une correction urgente a suivi dans la quinzaine. La largeur de cette fenêtre importe peu, à condition d’être la même d’un relevé au suivant.

Ajoutez à part une liste plus courte, celle des évolutions que vos équipes ont cessé de vous demander. Elles n’ont ni date ni motif écrit, puisqu’elles ne sont jamais devenues des demandes. Elles se comptent séparément et elles pèsent sur autre chose que le budget informatique : chacune est une possibilité commerciale que vous avez écartée pour une raison technique.

La lecture donne trois choses. Les deux dates de chaque ligne aboutie donnent votre délai réel, et sur dix lignes, une seule demande partie en dérive déplace la moyenne à elle seule, donc rangez les dix délais et prenez celui du milieu. Les corrections urgentes comptées sur les lignes abouties donnent votre part de régressions. Les motifs, relus ensemble, désignent la cause dominante : un motif de mise à niveau technique renvoie au socle, un motif d’incertitude sur l’existant renvoie aux règles non écrites, un motif de risque de casse renvoie aux contrôles manquants, un chiffrage qui déborde le périmètre demandé renvoie à la quatrième cause.

Un dernier contrôle vaut la peine. Si vos dix demandes portent toutes sur la même zone de l’application, ce n’est pas l’outil entier qui bloque, et le chantier se réduit d’autant.

Ce que vos dix demandes ne peuvent pas vous dire

Ce relevé désigne une cause. Il ne mesure pas ce que le chantier représente, et cela tient à sa nature même : il ne contient que ce que quelqu’un a pensé à demander. Les fonctions dont plus personne ne parle n’y figurent pas, ni les données qui les alimentent, ni l’état du socle sur lequel elles tournent. Ces trois éléments décident pourtant d’une bonne part du travail à prévoir, et ils ne se déduisent d’aucune liste de demandes.

Ce second relevé se prend dans l’application elle-même, et il se commande seul, sans engager la suite. Il consiste à ouvrir le code, les données et l’hébergement avant tout chiffrage, et ce qu’il produit vous reste, quelle que soit votre décision ensuite.

Votre classement, lui, vous sert quel que soit le prestataire que vous consultez ensuite, et il tient sur une page. Envoyez-le-nous si vous voulez la lecture d’un tiers avant d’ouvrir le sujet en interne. Quand c’est le périmètre que vos motifs désignent, la suite consiste à repartir de l’outil en service plutôt que du cahier des charges d’origine.

Sources

The Developer Coefficient, Stripe et Harris Poll, septembre 2018, https://stripe.com/files/reports/the-developer-coefficient.pdf

DORA’s software delivery performance metrics, DORA, Google Cloud, page mise à jour le 5 janvier 2026, consultée le 9 septembre 2026, https://dora.dev/guides/dora-metrics-four-keys/

A06:2021 Vulnerable and Outdated Components, OWASP Top 10:2021, dépôt GitHub officiel OWASP/Top10, consulté le 10 septembre 2026, https://github.com/OWASP/Top10/blob/master/2021/docs/en/A06_2021-Vulnerable_and_Outdated_Components.md

Strangler Fig Application, Martin Fowler, 22 août 2024, https://martinfowler.com/bliki/StranglerFigApplication.html