Nehos Groupe

L'essentiel

La TMA (Tierce Maintenance Applicative) est un contrat d'externalisation global qui couvre la maintenance corrective, préventive ET évolutive d'une application. Elle se distingue de la maintenance corrective simple, qui ne traite que les bugs.

Le terme 'tierce' désigne le fait que la prestation est confiée à un prestataire externe (tiers), et non à l'éditeur initial de l'application ni à l'équipe interne de la DSI.

Un contrat TMA type inclut : des SLA (temps de réponse et de résolution), un accès au repository Git, des rapports mensuels d'activité, une documentation technique maintenue et un interlocuteur dédié.

La TMA se différencie du support hotline (réponse aux utilisateurs) et du MCO (maintien en conditions opérationnelles, centré sur l'infrastructure) par son périmètre applicatif et ses engagements contractuels.

On bascule d'un support basique vers une TMA dès que l'application nécessite des montées de version régulières, accumule des incidents récurrents, ou que des évolutions fonctionnelles sont planifiées.

TMA vs maintenance corrective : quelle différence concrète pour votre SI ?

Définitions, types de contrats, SLA et critères pour choisir le bon dispositif de maintenance applicative.

Adapté à toute taille de structure

Artisan
Startup
PME / TPE
ETI
Grand Groupe
C
Chokri Siala
··tma

La TMA (Tierce Maintenance Applicative) couvre l'ensemble du cycle de vie d'une application externalisée : corrections de bugs, montées de version, évolutions fonctionnelles. La maintenance corrective, elle, ne traite que les anomalies. Comprendre cette différence est essentiel avant de signer un contrat.

#Qu'est-ce que la TMA ? Définition précise

La Tierce Maintenance Applicative est un contrat de prestation par lequel une entreprise confie à un prestataire externe (le « tiers ») la responsabilité opérationnelle d'une ou plusieurs applications métier. Le mot « tierce » est clé : il signifie que ni l'éditeur d'origine ni l'équipe interne de la DSI ne prend en charge la maintenance — c'est un acteur tiers, indépendant, qui s'y dédie.

Une TMA couvre trois axes :

  • Maintenance corrective : identifier, qualifier et corriger les anomalies logicielles (bugs bloquants, comportements inattendus, erreurs de calcul)
  • Maintenance préventive : appliquer les mises à jour de sécurité, monter les versions des frameworks et dépendances, effectuer des tests de non-régression
  • Maintenance évolutive : implémenter de nouvelles fonctionnalités dans le périmètre applicatif existant, adapter l'application aux évolutions réglementaires ou métier

Chez Nehos, une TMA complète sur une application Symfony/React représente typiquement 8 à 20 jours-homme par an, selon la complexité du périmètre et la fréquence des évolutions demandées.

#Les 3 types de maintenance : corrective, préventive, évolutive

#Maintenance corrective : traiter les anomalies

La maintenance corrective est le socle minimal. Elle intervient quand un bug est constaté : une fonctionnalité ne fonctionne plus, des données sont corrompues, une API retourne une erreur 500. Le prestataire analyse la cause racine, développe le correctif, le teste et le déploie.

On distingue deux niveaux :

  • Correctif urgent (P1) : application hors service, perte de chiffre d'affaires — délai de traitement attendu : 4 heures
  • Correctif standard (P2/P3) : anomalie non bloquante — délai : 24 à 72 heures

#Maintenance préventive : anticiper avant la crise

C'est le parent pauvre des contrats de maintenance, pourtant critique. Elle comprend :

  • Les montées de version (PHP 8.1 → 8.3, Symfony 5 → 7, Node 18 → 22…)
  • L'application des patchs de sécurité (CVE critiques)
  • Les tests de performance et les audits de dépendances
  • La mise à jour de la documentation technique

Sans maintenance préventive, une application de 3 ans accumule en moyenne 40 à 80 vulnérabilités connues — c'est ce que nos équipes constatent lors des audits de reprise.

#Maintenance évolutive : faire évoluer le produit

Elle couvre les nouvelles fonctionnalités qui s'intègrent dans l'existant : ajout d'un module d'export, intégration d'une API tierce, adaptation d'un workflow. Elle se distingue du développement projet (qui crée un nouveau produit) par son caractère incrémental sur une base de code existante.

#Pourquoi parle-t-on de « TMA » dans les contrats DSI ?

Le terme TMA s'est imposé dans le vocabulaire des DSI et des acheteurs publics pour une raison contractuelle précise : il permet de qualifier une prestation d'externalisation structurée avec des engagements de résultat (SLA), par opposition à un simple forfait de développement ou une régie sans engagement.

Dans les marchés publics et les contrats grands comptes (EDF, RATP, Groupama…), la TMA est souvent un lot distinct dans les appels d'offres, avec ses propres KPI, ses propres indicateurs de qualité et ses propres pénalités contractuelles.

Nos clients ETI utilisent le terme TMA dès lors qu'ils externalisent la maintenance d'une application critique avec un SLA formalisé. En dessous, on parle de « support » ou de « forfait de maintenance ».

#Ce qu'inclut un contrat TMA type

Un contrat TMA bien rédigé doit obligatoirement contenir les éléments suivants :

Élément contractuelCe qu'il doit préciser
Périmètre applicatifListe exhaustive des applications couvertes, versions, technologies
SLA par niveau de criticitéP1 : 4h réponse / 8h résolution ; P2 : 24h ; P3 : 72h
Capacité mensuelle incluseNombre de jours-homme réservés, gestion du report
Accès au repositoryGit (lecture/écriture), branches de production, procédure de déploiement
Documentation techniqueQui la maintient, format attendu, fréquence de mise à jour
Rapport mensuel d'activitéTickets traités, temps passé, dettes techniques identifiées, recommandations
Interlocuteur dédiéNom du responsable technique, escalade en cas d'indisponibilité
Conditions de sortiePréavis, procédure de transfert de connaissance, documentation de fin de contrat

Un contrat qui ne précise pas les SLA ou qui ne mentionne pas l'accès au code source n'est pas un contrat TMA sérieux — c'est un forfait de développement déguisé.

#TMA vs support hotline vs MCO vs forfait : le comparatif

CritèreTMASupport hotlineMCOForfait dév.
PérimètreApplicatif completAssistance utilisateursInfrastructure & serveursDéveloppement ponctuel
SLA formaliséOui (contractuel)Oui (basique)OuiNon
Accès au codeOui (obligatoire)NonNonOui (temporaire)
Maintenance préventiveOuiNonPartielleNon
Évolution fonctionnelleOui (dans périmètre)NonNonOui (hors périmètre)
Rapport mensuelOuiNonSelon contratNon
Engagement pluriannuel1-3 ansVariable1-3 ansPonctuel
Prix typique1 500–128 000 €/mois200–9 9 600 €/mois500–48 000 €/moisÀ la mission

Le MCO (Maintien en Conditions Opérationnelles) se concentre sur la disponibilité de l'infrastructure : serveurs, bases de données, réseaux, sauvegardes. Il est complémentaire de la TMA mais ne couvre pas le code applicatif. Une DSI qui confond MCO et TMA se retrouve avec des serveurs qui tournent mais des applications non maintenues.

#Quand passer d'un support basique à une TMA ?

Voici les 5 seuils qui signalent qu'un support ad hoc ne suffit plus :

  1. Montée de version imposée : votre hébergeur arrête le support de PHP 7.4, votre framework atteint son end-of-life — la maintenance préventive devient obligatoire.
  2. Incidents récurrents : plus de 3 tickets P1 par trimestre sur la même application révèlent une dette technique non traitée.
  3. Évolutions planifiées : si le product owner a une roadmap sur 6 mois, il faut un interlocuteur technique stable avec une capacité réservée.
  4. Application critique : toute application qui traite des données clients, des paiements ou des flux métier critiques mérite un SLA formalisé.
  5. Départ de l'équipe interne : quand le développeur qui connaissait l'application part, la TMA est le seul moyen de transférer cette connaissance de façon structurée.

Dans notre expérience de reprise de projets abandonnés, 80% des situations d'urgence auraient pu être évitées avec un contrat TMA couvrant la maintenance préventive.

#Ce qu'un bon contrat TMA contient obligatoirement

Au-delà du tableau de SLA, un contrat TMA solide précise :

  • La procédure d'onboarding : comment le prestataire prend connaissance de la base de code (audit initial, entretiens avec l'équipe sortante, revue de documentation)
  • La gestion des urgences hors SLA : que se passe-t-il si le site tombe un dimanche à 23h ?
  • Le plan de continuité : que fait le prestataire si son propre développeur dédié est indisponible ?
  • La propriété intellectuelle : tout le code produit dans le cadre de la TMA appartient au client, sans exception
  • La réversibilité : délai de préavis (généralement 3 mois), contenu du dossier de transfert de connaissance

Chez Nehos, notre service TMA inclut systématiquement un audit de reprise de 5 jours avant la prise en charge, pour ne jamais signer un contrat sur une base de code qu'on ne comprend pas. C'est notre protection et celle du client.

#Modernisation vs TMA : quand l'un précède l'autre

Il arrive qu'un audit de reprise révèle une dette technique telle qu'une TMA serait plus coûteuse que de repartir sur des bases saines. Dans ce cas, nous recommandons un projet de modernisation applicative avant la mise sous TMA.

Le critère : si le ratio coût-de-la-maintenance / valeur-de-l'application dépasse 30% par an, une refonte partielle (strangler pattern) est souvent plus rentable sur 3 ans.

Pour savoir où vous en êtes, notre outil de diagnostic de dette technique génère un score en 15 minutes.

#Combien coûte une TMA ? Premiers repères

Les fourchettes de marché varient selon la stack et la complexité :

Périmètre TMAFourchette mensuelle HT
Corrective seule (Symfony/PHP 8)800 –à partir de 1 500 €
Corrective + Préventive1 500 –56 000 €
TMA complète (C + P + E)3 500 –128 000 €
Legacy critique (COBOL, Oracle Forms)Sur devis (TJM premium)

Pour une analyse détaillée des modèles de facturation, consultez notre guide combien coûte une TMA applicative en 2026.

#Conclusion : TMA, le contrat de maturité applicative

La maintenance corrective est un filet de sécurité. La TMA est une stratégie. Elle transforme une application subie en actif maîtrisé, avec des SLA, une roadmap technique et un interlocuteur responsable. Pour toute application métier critique, c'est le standard minimal — pas un luxe.

Si vous voulez évaluer si votre application mérite une TMA, prenez 15 minutes avec nos experts.

Questions & Réponses

Questions fréquentes : TMA et maintenance applicative

Un SLA (Service Level Agreement) est un engagement contractuel sur la qualité de service. Dans une TMA, il précise les délais maximaux de prise en charge et de résolution des incidents, selon leur niveau de criticité. Exemple : un incident P1 (application hors service) doit être pris en charge en moins de 4 heures et résolu en moins de 8 heures. Le SLA inclut également le taux de disponibilité attendu (ex. 99,5% sur les heures ouvrables), les conditions de mesure et les pénalités financières applicables si les engagements ne sont pas tenus. Un contrat TMA sans SLA explicite n'offre aucune garantie réelle — c'est un engagement de moyens, pas de résultats.
Techniquement oui, mais c'est un contrat à risque pour les deux parties. Sans documentation, le prestataire TMA doit reconstituer la connaissance de l'application à partir du code source, des tickets passés et d'entretiens avec les équipes. Cela augmente le temps d'intervention, donc le coût. Chez Nehos, nous réalisons systématiquement un audit de reprise (inclus dans notre offre TMA) pour documenter l'architecture, les flux métier critiques et les zones de risque avant de signer. Si la documentation est inexistante, nous la produisons en phase d'onboarding — c'est un investissement qui se rentabilise dès le premier incident majeur.
La TMA et la gestion de la dette technique sont complémentaires mais ne se confondent pas. La TMA maintient l'application dans son état actuel (corriger, sécuriser, faire évoluer à la marge). La réduction de la dette technique est un projet à part entière, avec un budget et une roadmap dédiés. Un bon prestataire TMA identifie la dette dans ses rapports mensuels et propose des chantiers de refactoring priorisés. Chez Nehos, chaque rapport mensuel inclut un 'radar dette technique' qui évalue l'évolution du score sur les 4 dimensions : sécurité, obsolescence, testabilité et documentation.
La durée minimale d'un contrat TMA est généralement de 12 mois, pour deux raisons. D'abord, l'onboarding (audit de reprise, montée en compétence sur la base de code) représente un investissement de 5 à 10 jours non récupérables sur un contrat court. Ensuite, les SLA ne peuvent être tenus que si le prestataire a une connaissance suffisante de l'application — ce qui prend 2 à 3 mois. Un contrat de 3 mois est donc contra-indiqué. Les contrats de 24 ou 36 mois permettent en revanche de négocier de meilleures conditions tarifaires et d'engager des chantiers d'amélioration continue sur la durée.
Le coût d'un contrat TMA dépend de quatre facteurs principaux : la stack technologique (une application PHP 8 moderne coûte moins cher à maintenir qu'un système COBOL), la complexité fonctionnelle (nombre de modules, intégrations, règles métier), le niveau de SLA requis (un SLA 24/7 est plus cher qu'un SLA heures ouvrables) et le volume d'évolutions prévu. Sur le marché français, les fourchettes vont de à partir de 800 €/mois HT pour une TMA corrective simple, à partir de 32 000 €/mois HT pour une TMA complète sur une application critique multi-modules. Notre article dédié sur le [coût d'une TMA applicative](/blog/tma-maintenance-applicative/combien-coute-tma-applicative-2026) détaille les grilles tarifaires complètes.
Réserver un audit