La maintenance applicative regroupe l'ensemble des interventions réalisées sur une application après sa mise en production. Elle couvre la correction de bugs, les mises à jour de sécurité, les adaptations techniques et les évolutions fonctionnelles indispensables.
Le Risque d'Abandon
Négliger la maintenance expose l'application à des vulnérabilités de sécurité, une dégradation des performances et une incompatibilité croissante. Le coût de rattrapage est toujours bien supérieur à celui d'un entretien régulier.
Contrat & SLA
Un contrat bien structuré définit les SLA (temps de réponse/résolution), le périmètre et la fréquence des mises à jour. C'est un investissement qui protège la valeur de votre actif numérique dans la durée.
Les quatre types de maintenance
- Corrective — corriger un bug signalé ou détecté en production.
- Préventive — mettre à jour les dépendances, appliquer les correctifs de sécurité, surveiller ce qui pourrait casser avant que ça casse.
- Adaptative — suivre l'environnement : nouvelle version de PHP, fin de support d'un framework, changement d'API d'un partenaire, évolution réglementaire.
- Évolutive — ajouter ou faire évoluer des fonctionnalités au rythme du métier.
Beaucoup de contrats ne couvrent en réalité que la première. C'est la préventive et l'adaptative qui déterminent si l'application sera encore maintenable dans cinq ans.
Comment je la pratique
Maintenir une application, ce n'est pas attendre qu'elle casse. C'est faire en sorte qu'elle ne casse pas. Mes réflexes :
- Mettre à jour régulièrement, pas en urgence — de petites mises à jour fréquentes, chacune vérifiée par la CI, plutôt qu'une grosse remise à niveau tous les trois ans.
- Anticiper les fins de support — étudier les contraintes de chaque dépendance avant la prochaine version de PHP, et retirer d'abord ce qui ne sert plus.
- Surveiller l'absence de succès — une tâche planifiée qui ne tourne plus ne lève aucune erreur. Je préfère alerter quand une sauvegarde n'a pas réussi depuis trop longtemps plutôt qu'attendre un message d'échec qui ne viendra peut-être jamais.
- Vérifier les sauvegardes par la restauration — une sauvegarde jamais restaurée n'est qu'une hypothèse.
- Mutualiser l'outillage entre applications — image Docker commune, librairie partagée — pour qu'une correction profite à toutes.
Un exemple sur plus de dix ans
La première application que j'ai livrée pour la direction technique d'Orange, une application de gestion de tickets, a été mise en production en 2015. Pensée pour quelques mois, elle est toujours utilisée au quotidien. Entre-temps, PHP 5.6 est devenu PHP 8.4, Symfony est passé de la version 2 à la 6.4, AngularJS a été abandonné, et les applications ont été conteneurisées puis déployées sur OpenShift. Le périmètre s'est élargi à cinq applications, qui partagent une image Docker de base et une librairie PHP commune : quand je mets à jour l'image, toutes en bénéficient.
Cette longévité ne tient pas à une technologie particulière. Elle tient au fait que la dette est traitée au fil de l'eau, sans jamais laisser s'accumuler plusieurs versions de retard.
Les pièges
- Le contrat « au ticket » qui ne finance que le correctif : la préventive n'est jamais faite, et la facture arrive d'un coup sous forme de refonte.
- Des SLA sans supervision : un temps de réponse garanti n'a de sens que si l'on sait qu'un incident a lieu.
- Un mainteneur qui découvre l'application à chaque intervention : la connaissance du contexte métier est ce qui rend la maintenance efficace dans la durée.
La maintenance applicative n'est pas un coût, c'est l'assurance-vie de votre logiciel : elle garantit que votre outil reste performant, sûr et parfaitement aligné sur les besoins de vos utilisateurs.
Le détail de mon accompagnement est sur la page maintenance et évolution long terme d'applications web. Le retour d'expérience complet de cette mission est raconté dans plus de 10 ans de prestation freelance pour Orange.