Tierce maintenance applicative : ce que doit couvrir votre contrat TMA

La tierce maintenance applicative (TMA) consiste à confier à un prestataire externe la maintenance d'une application déjà en production. Une application livrée continue de coûter : incidents, mises à jour de sécurité, évolutions métier. Un bon contrat de TMA dit qui fait quoi, dans quel délai, pour quel prix, et comment en sortir. Voici ce qu'il doit contenir.

TMA, MCO, maintenance applicative : que couvre chaque terme ?

La maintenance applicative concerne le logiciel lui-même : analyse des incidents, corrections, mises à jour, tests et adaptations. La TMA (voir la définition dans notre glossaire) désigne le cas où un prestataire tiers en assume tout ou partie. Le MCO (maintien en conditions opérationnelles) est plus large : il inclut la supervision, les sauvegardes, les certificats et l'infrastructure.

La nuance compte au moment de signer. Un contrat de maintenance applicative ne couvre pas automatiquement l'hébergement, les sauvegardes ou les systèmes d'exploitation. Si le prestataire en est responsable, cela doit être écrit noir sur blanc.

Un contrat de TMA informatique doit donc commencer par un inventaire : applications, environnements (développement, recette, production), dépôts de code, bases de données, services cloud, APIs tierces. « Maintenance de l'application » sans inventaire est une formule trop vague pour être opposable.

Quels sont les 4 types de maintenance et quelle part du budget représentent-ils ?

Un contrat de maintenance informatique distingue quatre natures de travaux. La plupart des guides de Hydatis ou de Kern IT en retiennent trois (corrective, évolutive, préventive), et la quatrième, adaptative, est souvent rattachée à l'une des autres.

Quelle répartition viser ?

Il n'existe pas de répartition universelle, et nous ne connaissons aucune statistique publiée fiable qui le prétende. Tout dépend de l'âge, de la qualité du code et de la criticité de l'application.

Notre grille de cadrage, à ajuster après audit, ressemble à ceci : 25 à 40 % pour le correctif, 15 à 25 % pour le préventif et la sécurité, 10 à 20 % pour l'adaptatif, 25 à 45 % pour l'évolutif. Une application ancienne et peu testée fait basculer le budget vers le correctif.

Chez Fragments Studio, nous défendons une position simple : le préventif est le poste le plus souvent sacrifié, car il ne produit aucune fonctionnalité visible. Son absence augmente pourtant le coût de chaque correction et de chaque évolution suivante. C'est le mécanisme décrit dans notre article sur la dette technique : diagnostiquer, chiffrer et rembourser.

Pourquoi les correctifs de sécurité ne peuvent-ils pas attendre ?

Les failles récentes touchent des stacks très différentes, y compris les plus répandues :

• Next.js, mars 2025 : la faille CVE-2025-29927 permettait de contourner les contrôles d'accès du middleware avec un simple en-tête HTTP.
• React, décembre 2025 : React2Shell (CVE-2025-55182), notée 10 sur 10, ouvrait l'exécution de code à distance sur les serveurs utilisant les React Server Components, dont Next.js en App Router. Elle a été exploitée dans les jours suivant sa divulgation, et trois nouvelles failles ont été publiées une semaine plus tard, ce qui imposait un second déploiement.
• npm, septembre puis novembre 2025 : le ver Shai-Hulud a compromis plusieurs centaines de paquets pour voler les secrets des développeurs et des pipelines CI (analyse de Datadog).
• Linux, mars 2024 : la porte dérobée glissée dans xz-utils a rappelé qu'une brique système discrète peut aussi être visée.

Entre la publication d'un correctif et les premières attaques, il s'écoule parfois quelques heures. Une application dont les dépendances n'ont pas bougé depuis un an ne se corrige pas en une soirée : il faut d'abord rattraper le retard de versions, puis tester, puis déployer. Le préventif sert précisément à rester à quelques versions près, pour que le correctif urgent soit une mise à jour de routine.

Exigez donc dans le contrat :

• une veille des vulnérabilités sur toutes les dépendances, avec des outils comme Dependabot ou Renovate et les avis de sécurité des éditeurs ;
• un délai maximal de déploiement des correctifs critiques, par exemple 24 à 72 heures selon l'exposition de l'application ;
• une chaîne de déploiement capable de livrer hors cycle, sans attendre la prochaine version planifiée ;
• un suivi écrit : failles détectées, applications concernées, date de correction ou justification si le correctif est reporté.

Que doit prévoir votre contrat de TMA : SLA, délais, astreinte, monitoring ?

Un contrat TMA efficace fixe des engagements mesurables sur quatre sujets : la criticité des incidents, les délais d'intervention, les horaires de couverture et la supervision.

Quels niveaux de criticité et quels SLA ?

Un SLA (Service Level Agreement, voir le glossaire) est l'engagement écrit du prestataire sur des délais et un niveau de service. Une classification en quatre niveaux reste la plus lisible :

• P1 (bloquant) : le service est indisponible ou une fonction essentielle est inutilisable.
• P2 (majeur) : dégradation importante, contournement limité.
• P3 (mineur) : anomalie sans impact critique.
• P4 (demande) : question ou amélioration non urgente.

Chaque niveau reçoit ses propres délais. À titre de cadrage, on retrouve souvent une prise en compte sous 2 à 4 heures pour un P1 et 8 à 24 heures pour un P2. Ces valeurs dépendent de la criticité réelle de votre service et de votre budget.

Exigez de distinguer le délai de prise en compte, de diagnostic, de contournement et de rétablissement. Méfiez-vous d'un « délai de résolution » garanti quand le prestataire ne maîtrise pas toutes les dépendances : un délai de rétablissement est plus honnête.

Faut-il une astreinte ?

Une astreinte est une permanence qui permet d'intervenir hors horaires ouvrés. Le contrat doit préciser les jours et horaires couverts, les incidents qui la déclenchent, le canal d'urgence, le délai de rappel et le tarif des interventions de nuit ou de week-end.

Une astreinte 24/7 n'a de valeur que si la détection d'incident existe réellement. Sans alerte automatique, la permanence ne sert à rien : vous découvrez la panne par vos utilisateurs.

Quel monitoring et quels rapports ?

Le monitoring (supervision) doit couvrir la disponibilité, les temps de réponse, les erreurs applicatives, les files de traitement, les certificats, les sauvegardes et les alertes de sécurité. Notre article sur NestJS Observe et l'observabilité native montre ce que cela donne concrètement côté code.

Ajoutez un rapport mensuel : incidents par criticité, délais réels, incidents récurrents, crédit d'évolution consommé, actions préventives réalisées, vulnérabilités détectées et délai de correction de chacune. C'est votre tableau de bord pour décider de renouveler ou non.

Quelles clauses sur les tests, la sécurité et les accès ?

Le contrat doit aussi dire qui écrit les tests, qui valide la recette, qui autorise la mise en production et comment se gèrent les retours arrière. Côté sécurité, exigez des comptes nominatifs, une authentification forte, la traçabilité des interventions et la révocation des accès en fin de contrat.

Combien coûte une TMA : forfait, crédit d'heures ou régie ?

Il n'existe pas de tarif standard. Selon Castelis, le coût dépend de la taille et de la complexité de l'application, de son état technique, du volume d'incidents attendu et du niveau de service demandé.

Pour les ordres de grandeur, GoLive Software cite environ 300 à 450 € par jour en nearshore et 500 à 750 € pour une société française, selon le profil. Les forfaits publiés par les prestataires vont de quelques centaines d'euros par mois pour un faible volume de support à plusieurs milliers pour une application critique.

Notre conseil : corrective et préventive se prêtent bien au forfait, car leur volume s'estime à partir de l'existant. L'évolutive dépend de vos décisions et se pilote mieux en crédit d'heures. Combiner les deux est la formule la plus courante.

Pour comparer des offres, demandez un chiffrage séparé de la reprise initiale, de l'audit, de la maintenance récurrente, des évolutions, de l'astreinte, des outils de monitoring et de la réversibilité. Un prix très bas sans périmètre détaillé cache presque toujours des exclusions ou l'absence d'engagement sur les délais.

Comment changer de prestataire de maintenance sans risque ?

La réversibilité est la capacité à transmettre l'application à une autre équipe sans dépendre du prestataire sortant. Elle se négocie à la signature, pas au moment du départ.

Le plan de réversibilité en est le document de référence. Il doit lister au minimum :

• le code source complet et son historique de versions ;
• les scripts de déploiement et les fichiers de configuration ;
• les schémas de base de données et la documentation d'architecture ;
• les comptes, droits d'accès et secrets, transmis selon une procédure sécurisée ;
• les tests automatisés, les sauvegardes et l'historique des incidents ;
• une période de transfert avec sa durée, ses livrables et son prix.

Posez quatre questions avant de signer. Qui détient les comptes cloud et les noms de domaine ? Les dépôts de code vous appartiennent-ils ? La documentation est-elle mise à jour pendant le contrat ? Les coûts de transfert sont-ils plafonnés ?

Une clause sans test reste théorique. Prévoyez chaque année une restauration de sauvegarde, une revue de documentation et un redéploiement sur un environnement vierge. Si vous héritez d'un existant dans le désordre, notre article sur la reprise d'un projet mal développé détaille la marche à suivre.

Questions fréquentes

Qu'est-ce que la tierce maintenance applicative ? La tierce maintenance applicative est la prise en charge de la maintenance d'une application par un prestataire externe. Elle couvre les corrections, les évolutions et la prévention, selon un contrat qui précise périmètre, délais et tarifs.

Quelle différence entre TMA et MCO ? La TMA porte sur le logiciel : bugs, évolutions, mises à jour. Le MCO couvre aussi l'exploitation : supervision, sauvegardes, certificats, infrastructure. Une TMA peut inclure du MCO, mais ce n'est pas automatique.

Comment choisir entre forfait, crédit d'heures et régie ? Choisissez le forfait pour le correctif et le préventif d'une application stable. Prenez un crédit d'heures pour des évolutions irrégulières. Réservez la régie aux projets actifs qui demandent un renfort rapide. Beaucoup de contrats associent un forfait de base et un crédit d'évolution.

Pourquoi la réversibilité est-elle importante dans un contrat de maintenance ? Sans elle, vous dépendez d'un seul prestataire pour comprendre, déployer et faire évoluer votre application. La réversibilité garantit que le code, la documentation et les accès vous reviennent, et rend la concurrence possible à chaque renouvellement.

Conclusion

Un contrat de tierce maintenance applicative ne se résume pas à un forfait ou à un nombre de jours. Il décrit un périmètre, quatre types de travaux, des niveaux de criticité, des SLA, une astreinte, un monitoring, un modèle de facturation et une sortie organisée.

Notre recommandation : faire précéder la signature d'un audit technique (état du code, dette, documentation, fréquence des incidents). Le budget de maintenance devient alors une décision chiffrée, et non un forfait choisi à l'aveugle.

Reprendre ou cadrer la maintenance de votre application

Si votre application tourne sans filet ou si votre prestataire actuel ne tient plus ses engagements, nous pouvons auditer l'existant et structurer un contrat clair.

• Découvrez notre offre de reprise de projet pour auditer, stabiliser et reprendre une application existante.
• Pour la supervision, les déploiements et l'infrastructure, consultez notre expertise cloud et DevOps.
• Si votre projet implique un outil interne à faire évoluer, notre équipe développement sur-mesure peut vous accompagner.
• Obtenez une première estimation via notre estimateur de projet.
• Ou parlons-en directement.