Après la mise en production, une application web a besoin de quatre types de travaux : corriger les anomalies, adapter l’application à son environnement technique qui évolue, prévenir les pannes et les failles, et faire évoluer les fonctionnalités avec le métier. La maintenance n’est donc pas une option : c’est ce qui garde l’application sûre, rapide et utile. La TMA (tierce maintenance applicative) consiste à confier ces travaux à un prestataire dans un contrat qui fixe des niveaux de service mesurables.
Ce guide s’adresse aux dirigeants qui viennent de livrer (ou s’apprêtent à livrer) une application métier et qui se demandent ce qu’il faut organiser pour la suite : périmètre, engagements, indicateurs, budget temps et pièges contractuels.
Pourquoi une application qui fonctionne a-t-elle besoin d’entretien ?
Une application web n’est pas un objet figé. Elle repose sur des dizaines de briques externes : un environnement d’exécution (Node.js, PHP, Java…), des bibliothèques open source, une base de données, un hébergeur, des API de partenaires, des navigateurs. Chacune de ces briques évolue selon son propre calendrier.
Prenons l’exemple de Node.js, très utilisé pour les applications web. Son projet indique que les versions à support long terme garantissent en général la correction des bugs critiques pendant 30 mois au total, et que les applications de production ne devraient utiliser que des versions en support actif ou en maintenance (Node.js). Autrement dit : une application livrée aujourd’hui devra changer de version d’environnement d’exécution avant trois ans, même si personne ne touche à ses fonctionnalités.
La sécurité suit la même logique. L’OWASP, référence mondiale en sécurité applicative, classe les défaillances de la chaîne d’approvisionnement (dépendances vulnérables, composants non maintenus) au troisième rang de son Top 10 2025, et précise que la moitié des répondants de son enquête communautaire les ont placées en première position (OWASP). Une application que l’on ne met jamais à jour accumule des failles publiquement documentées.
Les quatre familles de maintenance, et ce qu’elles recouvrent
On distingue classiquement quatre familles de travaux. Les nommer clairement évite la première source de litige en TMA : le désaccord sur ce qui est « inclus ».
| Famille | Objectif | Exemples concrets | Déclencheur |
|---|---|---|---|
| Corrective | Corriger une anomalie constatée | Un calcul de remise faux, un export qui échoue, une page qui ne s’affiche plus | Signalement d’un utilisateur ou alerte de supervision |
| Adaptative | Suivre l’environnement technique et réglementaire | Montée de version de l’environnement d’exécution, nouvelle version d’une API partenaire, nouvelle mention légale sur les factures | Calendrier externe |
| Préventive | Éviter les pannes et les failles futures | Mises à jour de sécurité, nettoyage de la dette technique, optimisation d’une requête lente, test de restauration | Plan de maintenance |
| Évolutive | Apporter de la valeur métier | Nouveau tableau de bord, nouveau workflow de validation, connexion à un nouvel outil | Feuille de route métier |
La maintenance corrective concerne les défauts de l’application telle qu’elle a été spécifiée. La maintenance évolutive concerne ce qui n’a jamais été demandé. Cette frontière doit être écrite noir sur blanc : « l’export ne contient pas la colonne X » est une anomalie si la colonne figurait dans les critères d’acceptation, une évolution sinon. C’est l’intérêt d’avoir des user stories avec critères d’acceptation et une recette documentée : elles servent de référence pendant toute la vie de l’application.
Le socle invisible : supervision et sauvegardes
À ces quatre familles s’ajoute l’exploitation courante, souvent oubliée dans les contrats : supervision de la disponibilité, alertes, gestion des certificats, renouvellement des noms de domaine, surveillance de l’espace disque, sauvegardes.
Sur les sauvegardes, la CNIL rappelle des règles simples qui devraient figurer dans tout plan de maintenance : stocker au moins une sauvegarde sur un site géographiquement distinct, en isoler au moins une hors ligne, les protéger au même niveau que les données de production, et tester régulièrement l’intégrité des sauvegardes et la capacité de les restaurer (CNIL). Une sauvegarde jamais restaurée n’est qu’une hypothèse.
Quels engagements de service fixer ?
Les engagements se formalisent avec trois notions empruntées à l’ingénierie de la fiabilité, définies par Google dans son ouvrage de référence (Google SRE) :
- Un SLI (indicateur de niveau de service) est une mesure quantitative d’un aspect du service : taux de disponibilité, temps de réponse, taux d’erreur.
- Un SLO (objectif de niveau de service) est la valeur cible fixée pour cet indicateur.
- Un SLA (accord de niveau de service) est l’engagement contractuel qui associe des conséquences au respect ou non de ces objectifs.
Pour une application métier de PME ou d’ETI, l’essentiel tient souvent dans une grille de gravité. Voici une trame à adapter (les délais sont à négocier selon la criticité réelle de l’outil, pas à recopier) :
| Gravité | Définition | Exemple | Ce qu’il faut fixer |
|---|---|---|---|
| Bloquante | L’application ou une fonction vitale est indisponible pour tous | Impossible de saisir une commande | Délai de prise en charge court, contournement puis correction, plages horaires couvertes |
| Majeure | Une fonction importante est dégradée, un contournement existe | Le calcul des délais de livraison est faux sur un cas précis | Délai de prise en charge, délai de correction en jours ouvrés |
| Mineure | Gêne sans impact sur l’activité | Libellé erroné, tri incorrect dans une liste | Correction groupée dans la prochaine version |
Deux précisions évitent bien des déceptions. D’abord, distinguer délai de prise en charge (quelqu’un qualifie le problème) et délai de résolution (le problème est corrigé ou contourné). Ensuite, définir les plages couvertes : jours ouvrés, horaires de bureau, astreinte le week-end. Une couverture étendue mobilise davantage de personnes ; elle n’a de sens que si l’application est réellement critique en dehors des heures de bureau.
Comment s’organise une TMA au quotidien ?
Une TMA efficace repose sur un circuit court et outillé, pas sur des échanges d’e-mails.
- Un point d’entrée unique pour les demandes : un outil de tickets accessible aux référents métier, avec des champs obligatoires (écran concerné, étapes pour reproduire, gravité proposée, capture).
- Une qualification rapide par le prestataire : anomalie ou évolution, gravité confirmée, estimation pour les évolutions.
- Un arbitrage régulier des évolutions par le client : un comité mensuel ou trimestriel qui priorise selon la valeur métier.
- Des livraisons fréquentes et sûres : environnement de recette, tests automatisés, mise en production planifiée, possibilité de revenir en arrière.
- Un rapport périodique : incidents, délais tenus, mises à jour appliquées, temps consommé, recommandations.
Pour mesurer la santé du processus de livraison, les indicateurs DORA sont devenus un standard. Ils suivent notamment la fréquence de déploiement, le délai entre une modification et sa mise en production, le taux de déploiements qui nécessitent une intervention immédiate et le temps de rétablissement après un déploiement raté (DORA). Inutile de tout suivre dès le premier mois ; deux ou trois indicateurs bien choisis suffisent à voir si la maintenance s’améliore ou se dégrade.
Forfait, carnet de tickets ou équipe dédiée : quel modèle choisir ?
Trois modèles de contrat coexistent, et le bon choix dépend surtout du volume et de la prévisibilité des demandes.
| Modèle | Principe | Adapté quand | Point de vigilance |
|---|---|---|---|
| Forfait de maintien en conditions opérationnelles | Un socle récurrent couvre supervision, mises à jour, corrections | L’application est stable, les évolutions sont rares | Bien lister ce qui est exclu |
| Carnet d’unités d’œuvre | Un volume de temps acheté à l’avance, décompté à la demande | Les besoins sont ponctuels et variables | Suivre la consommation pour ne pas épuiser le carnet sur des urgences |
| Équipe dédiée ou capacité réservée | Une capacité fixe chaque mois, priorisée par le client | L’application évolue en continu avec le métier | Exiger une feuille de route et des démonstrations régulières |
Dans la pratique, le montage le plus sain combine un socle fixe (sécurité, supervision, sauvegardes, corrections) et une capacité d’évolution ajustable. Il protège l’essentiel même quand le budget d’évolution est réduit. Le choix entre forfait et temps passé suit la même logique que pour le projet initial, détaillée dans notre article sur le forfait, la régie et le forfait par lots.
Les pièges à éviter dans un contrat de maintenance
Quelques clauses font la différence entre une TMA sereine et une dépendance subie :
- Le périmètre flou. « Maintenance de l’application » ne veut rien dire. Listez les composants, les environnements, les intégrations et les familles de travaux couverts.
- L’absence d’accès. Le client doit détenir les accès administrateur à l’hébergement, au dépôt de code et aux noms de domaine. C’est la condition de toute réversibilité.
- Pas de documentation à jour. Exigez que chaque évolution mette à jour la documentation technique et le guide d’exploitation.
- La dette technique jamais traitée. Réservez explicitement une part du temps à la maintenance préventive, sinon l’urgence l’emporte toujours. Notre article sur la dette technique explique comment la rendre visible.
- Les mises à jour repoussées. Une montée de version d’environnement d’exécution faite chaque année est un petit chantier ; faite tous les cinq ans, c’est une refonte.
- Une sortie non prévue. Fixez dès le départ la durée de transition, les livrables de fin de contrat et l’accompagnement d’un éventuel successeur.
La checklist avant la mise en production
Avant de mettre une application en service, vérifiez que ces éléments sont prêts :
- Supervision active (disponibilité, erreurs, temps de réponse) avec destinataires des alertes identifiés.
- Sauvegardes automatiques, copie externalisée et premier test de restauration réalisé.
- Inventaire des dépendances et des versions, avec une veille de sécurité en place.
- Grille de gravité et délais validés par le métier.
- Outil de tickets ouvert aux référents, avec un modèle de demande.
- Accès administrateur détenus par l’entreprise, documentation d’exploitation remise.
- Calendrier des prochaines montées de version majeures connu.
- Premier comité de pilotage de la maintenance planifié.
C’est la démarche que nous appliquons sur chaque application web sur mesure livrée : la mise en production marque le début de la vie de l’outil, pas la fin du projet. Vous voulez faire le point sur l’état de votre application actuelle ou préparer la maintenance d’un projet à venir ? Décrivez votre situation dans notre diagnostic de projet, nous revenons vers vous avec une première analyse.
