Agence Maintenance applicative
Un produit digital ne se dégrade pas d'un coup. Il vieillit par petites touches, pendant que personne ne regarde : une dépendance qui n'est plus maintenue, un service tiers qui change son API, un navigateur qui durcit ses règles. Voici comment nous regardons ce vieillissement, et ce que nous en faisons.
Cinq choses qui font vieillir un produit
Les dépendances
Une application repose sur des centaines de bibliothèques qu'elle ne contrôle pas. Chacune a son rythme de mise à jour, ses failles et sa date de fin de support.
Les services tiers
Paiement, cartographie, mesure d'audience, authentification : leurs API changent, leurs versions sont retirées, et le préavis est rarement à votre convenance.
Les navigateurs et les systèmes
Ce qui fonctionnait se déprécie, les règles de confidentialité se durcissent, les comportements par défaut changent sans prévenir.
La réglementation
Accessibilité, données personnelles, obligations sectorielles : la conformité d'hier ne vaut pas pour demain.
Les usages
Vos utilisateurs changent d'habitudes plus vite que votre interface. Un parcours qui convertissait il y a trois ans ne convertit plus forcément aujourd'hui.
La dette technique n'est pas une métaphore
On parle de dette parce qu'elle se comporte exactement comme une dette : elle a été contractée pour aller plus vite à un moment donné, et elle produit des intérêts. Ces intérêts ont des noms très concrets. Chaque évolution prend plus de temps que la précédente. Chaque correctif en casse un autre. Chaque nouveau développeur met plus longtemps à devenir productif.
Contracter une dette technique n'est pas une faute : sortir à temps vaut parfois mieux qu'un code parfait livré trop tard. Le problème n'est pas d'en avoir, c'est de ne pas savoir combien on en a. Un état des lieux régulier transforme une inquiétude diffuse en décision chiffrable.
Ce que nous surveillons
La sécurité
Les failles connues dans les dépendances, et les correctifs disponibles qui n'ont pas été appliqués.
La performance
Les Web Vitals se dégradent par ajouts successifs, presque jamais par une régression unique.
L'accessibilité
La conformité se vérifie, elle ne se décrète pas une fois pour toutes.
L'obsolescence
Ce qui approche de sa fin de support, et le temps dont on dispose encore pour agir sereinement.
Les erreurs en production
Y compris celles que personne ne remonte, parce que l'utilisateur a simplement renoncé.
Entretenir ou refondre
Entretenir suffit quand
- L'architecture tient et les fondations sont saines.
- Le produit répond encore au besoin métier.
- La dette est identifiée et circonscrite.
- Une équipe est capable de reprendre le code.
- Les utilisateurs n'ont pas de reproche de fond à formuler.
Refondre s'impose quand
- Le socle n'est plus supporté par son éditeur.
- Chaque évolution coûte davantage que la précédente.
- Le modèle de données ne correspond plus au métier.
- La sécurité ne peut plus être tenue.
- Plus personne ne sait comment le produit fonctionne.
Le réflexe de refondre tous les quatre ans est souvent un aveu : le produit n'a pas été entretenu. Une refonte coûte plusieurs fois ce qu'aurait coûté l'entretien, et elle remet à zéro les habitudes que vos utilisateurs avaient fini par acquérir.
Questions fréquentes
Vous voulez passer à la mise en œuvre ?
Le déroulé, les livrables et les modalités sont détaillés sur notre page prestation.
Voir la prestation maintenanceMaintenance applicative : vieillissement, dette technique et arbitrages
Un produit digital vieillit sur cinq fronts simultanés : ses dépendances logicielles, les services tiers auxquels il est branché, les navigateurs et systèmes d'exploitation, la réglementation qui le concerne, et les usages de ceux qui s'en servent. Aucun de ces fronts ne relève d'un choix : le vieillissement est la condition normale d'un logiciel en ligne, et la question n'est pas de l'éviter mais de le regarder en face.
La dette technique est la forme la plus documentée de ce vieillissement. Contractée pour livrer plus vite, elle produit des intérêts mesurables : évolutions plus lentes, correctifs qui cassent, montée en compétence difficile des nouveaux développeurs. Son montant n'est pas une question d'opinion : un état des lieux du code et des dépendances permet de le chiffrer et de décider en connaissance de cause.
La surveillance porte sur cinq postes : la sécurité des dépendances, la performance mesurée par les Web Vitals (que nous traitons dans notre expertise performance et éco-conception), la conformité d'accessibilité qui se vérifie régulièrement, l'obsolescence des composants en fin de support, et les erreurs de production que les utilisateurs ne remontent jamais. Ces surveillances pèsent directement sur les choix d'architecture faits en amont, décrits dans notre expertise front et headless.
L'arbitrage entretenir ou refondre se décide sur des critères objectifs : santé du socle, adéquation au métier, coût croissant des évolutions, sécurité, connaissance du code. Quand ces critères basculent, la suite n'est plus de la maintenance mais un projet de changement de plateforme, cadré comme tel.
Cette page décrit la méthode et les principes. Le déroulé de mission, les livrables, le périmètre couvert et les modalités de dimensionnement sont détaillés sur notre prestation de maintenance et TMA.
Newsletter Agence Wex
Recevez nos derniers articles, retours d'expérience et bonnes pratiques UX directement dans votre boîte mail.
Désinscription possible à tout moment. Pas de spam, pas de revente de données.
Ce formulaire est protégé par reCAPTCHA : la politique de confidentialité et les conditions d'utilisation de Google s'appliquent.