Maintenance évolutive d’une application : organiser l’après-lancement

Une application métier mise en ligne n’est pas terminée : elle entre en service. Dès les premières semaines, les utilisateurs signalent des cas imprévus, les systèmes d’exploitation et les navigateurs évoluent, les bibliothèques utilisées publient des correctifs. La maintenance évolutive consiste à faire avancer l’outil avec l’activité, tandis que la maintenance corrective le garde en état de marche. Les deux se préparent avant le lancement, pas au premier incident.

Cet article vous aide à distinguer ces prestations, à repérer ce qu’un contrat doit préciser et à organiser les évolutions sans transformer chaque demande en urgence.

Corrective, préventive, évolutive : trois besoins différents

On regroupe souvent tout sous le mot « maintenance », alors que les attentes ne sont pas les mêmes. La maintenance corrective traite ce qui ne fonctionne pas comme prévu : un calcul faux, un écran qui ne s’affiche plus, un export incomplet. La maintenance préventive, parfois appelée adaptative, maintient l’application compatible avec son environnement : mises à jour de sécurité, nouvelles versions du langage ou du framework, changement d’hébergement. La maintenance évolutive ajoute ou modifie des fonctionnalités parce que le besoin a changé : un nouveau statut de dossier, un rôle supplémentaire, une connexion à un autre outil.

Quand ces prestations sont confiées à un prestataire extérieur, on parle de tierce maintenance applicative, ou TMA. Le terme ne dit rien, à lui seul, de ce qui est couvert. Un contrat de TMA peut n’inclure que la correction d’anomalies ; un autre peut prévoir un volume d’évolutions. C’est ce périmètre qu’il faut lire, pas l’intitulé.

Pourquoi une application qui ne change pas se dégrade quand même

Une application s’appuie sur des éléments qu’elle ne contrôle pas : système d’exploitation, navigateur, bibliothèques open source, services tiers, hébergement. Chacun évolue à son rythme. L’ANSSI le rappelle dans ses règles de base : un appareil ou un logiciel qui n’est pas à jour devient vulnérable. Une dépendance jamais mise à jour finit par porter des failles connues, et plus l’écart grandit, plus la mise à niveau demande de travail.

Pour une application mobile, la contrainte est aussi fixée par les magasins d’applications. Google Play impose par exemple aux nouvelles applications et aux mises à jour de cibler un niveau d’API Android récent ; une application existante qui ne suit pas cesse d’être proposée aux nouveaux utilisateurs dont l’appareil fonctionne sous une version plus récente d’Android. Sans intervention régulière, l’application reste en ligne mais devient progressivement moins accessible.

Ce qu’un accord de maintenance doit préciser

Avant de comparer des offres, listez les questions auxquelles le contrat doit répondre. Elles valent aussi bien pour l’équipe qui a construit l’outil que pour un nouveau prestataire.

• Périmètre : quelles prestations sont incluses (correction, mises à jour, évolutions) et lesquelles font l’objet d’un devis à part ?
• Signalement : par quel canal un incident est-il remonté, par qui, et avec quelles informations ?
• Délais : quels délais de prise en compte et de résolution sont engagés, selon la gravité, et sur quelles plages horaires ?
• Priorités : qui décide de l’ordre des évolutions, et à quel rythme les demandes sont-elles arbitrées ?
• Environnements : existe-t-il un environnement de test séparé de la production, et qui valide avant une mise en ligne ?
• Accès et documentation : où sont le code, les accès d’hébergement et la documentation, et à qui appartiennent-ils ?
• Fin de contrat : comment l’application, les données et les accès sont-ils remis si vous changez de prestataire ?

Un délai d’intervention n’a de valeur que s’il est écrit, avec sa définition. « Prise en compte sous un jour ouvré » et « correction sous un jour ouvré » ne promettent pas la même chose. Méfiez-vous d’une formule qui garantit une disponibilité ou une réactivité sans en préciser les conditions.

Organiser la maintenance évolutive au quotidien

Les demandes d’évolution arrivent de partout : un chef d’équipe par téléphone, un utilisateur par email, la direction lors d’une réunion. Sans point de collecte unique, les plus insistantes passent avant les plus utiles. Désignez une personne référente côté entreprise, chargée de recevoir les demandes, de les reformuler et de les classer.

Pour chaque demande, trois informations suffisent souvent à décider : le problème rencontré, décrit avec un exemple réel ; les personnes concernées et la fréquence ; ce qui se passe si rien ne change. Une demande formulée comme une solution (« ajouter un bouton ici ») gagne à être reformulée comme un besoin (« retrouver les dossiers en attente de validation »). Le prestataire peut alors proposer la réponse la plus simple, qui n’est pas toujours celle imaginée au départ.

Un rendez-vous régulier, dont la fréquence dépend du volume de demandes, permet d’arbitrer la liste et de décider de ce qui entre dans la prochaine livraison. Chaque évolution est testée sur un environnement de recette avant la mise en production, par une personne qui connaît le métier. C’est le moyen le plus sûr d’éviter qu’une correction en casse une autre.

Les erreurs qui coûtent cher

• Reporter les mises à jour techniques parce qu’elles ne se voient pas : l’écart s’accumule jusqu’à rendre la mise à niveau lourde.
• Mélanger incidents et évolutions dans la même file : une demande de confort bloque alors la correction d’une anomalie.
• Ne pas mettre à jour la documentation : la connaissance reste dans la tête d’une personne.
• Laisser tous les accès chez le prestataire : le jour où vous voulez en changer, la reprise devient compliquée.
• Ajouter des fonctionnalités sans jamais en retirer : l’outil s’alourdit et les écrans deviennent difficiles à lire.

Reprendre une application développée par quelqu’un d’autre

Il arrive que l’équipe d’origine ne soit plus disponible. Une reprise commence alors par un état des lieux : accès au code et à l’hébergement, version des composants, présence de tests, documentation existante, anomalies connues. Cet inventaire dit si l’application peut être maintenue telle quelle, si elle demande d’abord une remise à niveau, ou si la question d’une refonte progressive de l’application se pose.

Quand vous faites développer un logiciel métier sur mesure, parlez de la maintenance dès la proposition. Les choix faits au départ — composants retenus, tests automatisés, documentation, remise des accès — conditionnent le coût et la facilité des évolutions pendant toute la vie de l’outil.