Tierce maintenance applicative (TMA) : le guide

16 octobre 2026
Imed AMMAR
Blog

Une application critique à maintenir ?

La tierce maintenance applicative (TMA) consiste à confier à un prestataire externe la maintenance et l’évolution d’applications existantes : correction des anomalies, évolutions fonctionnelles, adaptation à l’environnement technique et support, selon des niveaux de service définis par contrat. Ce guide détaille le périmètre d’une TMA, les modèles de contrat, les indicateurs à exiger et les étapes d’une reprise réussie.

Qu’est-ce que la tierce maintenance applicative ?

Le mot « tierce » signifie que la maintenance est assurée par un tiers, distinct de l’équipe qui a développé l’application. La TMA porte sur le logiciel : son code, ses fonctionnalités et ses données applicatives. Elle ne couvre pas, en principe, l’infrastructure (serveurs, réseaux, postes de travail), qui relève de l’infogérance.

On y recourt typiquement dans quatre situations : l’équipe interne passe plus de temps sur les incidents que sur la feuille de route, le développeur d’origine est parti, une application critique doit être stabilisée, ou l’entreprise veut transformer un coût difficile à prévoir en un service mesuré.

Les quatre types de maintenance

La terminologie courante s’inspire de la norme ISO/IEC 14764, qui distingue plusieurs catégories de maintenance logicielle.

Maintenance corrective : analyse et correction des anomalies et des incidents de production, jusqu’à la clôture.
Maintenance évolutive : nouvelles fonctionnalités et adaptations métier, priorisées avec vos équipes.
Maintenance adaptative : adaptation de l’application aux changements de son environnement : système d’exploitation, base de données, navigateurs, interfaces avec d’autres applications, réglementation.
Maintenance préventive : actions menées avant l’incident : mises à jour de sécurité, refactoring, réduction de la dette technique, supervision.

Les niveaux de support : N1, N2 et N3

Niveau 1 : accueil, qualification de la demande et résolution par des procédures documentées. Il est souvent assuré par le support interne du client.
Niveau 2 : analyse applicative, reproduction du problème et correctifs courants. Il demande une bonne connaissance de l’application.
Niveau 3 : expertise approfondie, intervention sur le code, résolution des causes racines et traitement des problèmes d’architecture.

Dans un contrat de TMA, le prestataire prend en général en charge les niveaux 2 et 3, et parfois le niveau 1.

TMA, infogérance, MCO : ne pas confondre

L’infogérance concerne l’exploitation de l’infrastructure. La TMA concerne les applications. Le MCO (maintien en condition opérationnelle) désigne l’ensemble des activités qui gardent un système opérationnel ; selon les contrats, il peut inclure la TMA. Enfin, le « run » regroupe l’exploitation et la maintenance d’un système en production, par opposition au « build », qui désigne les nouveaux projets.

Forfait, régie, unités d’œuvre : quel modèle de contrat ?

Au forfait : le prestataire s’engage sur un périmètre applicatif et des niveaux de service pour un prix fixe, mensuel ou annuel. Ce modèle convient lorsque le volume d’activité est prévisible et mesurable.
En régie (assistance technique) : des ingénieurs sont mis à votre disposition et facturés au temps passé. La souplesse est maximale, mais l’engagement du prestataire porte sur les moyens, pas sur le résultat.
À l’unité d’œuvre : la facturation dépend du nombre de tickets ou du volume de travail traité. Ce modèle s’adapte aux volumes variables, à condition de bien définir l’unité.
Mixte : un socle forfaitaire pour le support et les corrections, complété par une enveloppe d’évolutions en régie. C’est souvent le meilleur compromis.

Pour choisir, posez-vous deux questions : le périmètre est-il stable et mesurable ? Avez-vous les moyens de piloter vous-même les ressources ? Si le périmètre est stable et que vous ne pouvez pas piloter les ressources, le forfait est le plus adapté. Si le besoin évolue sans cesse, la régie ou le modèle mixte conviennent mieux.

Les niveaux de service (SLA) à exiger

Sans niveaux de service mesurables, vous n’avez aucun moyen de savoir si le service est réellement rendu. Les indicateurs les plus utiles :

le délai de prise en compte d’un incident ;
le délai de contournement et le délai de résolution, selon la criticité (bloquant, majeur, mineur) ;
la plage de couverture : heures ouvrées ou astreinte étendue ;
le taux de respect des délais convenus ;
le taux de récurrence des incidents et le nombre de régressions après livraison ;
la satisfaction des utilisateurs métier.

Ces indicateurs doivent être mesurés de la même façon par les deux parties, présentés dans un rapport mensuel et revus lors d’un comité de pilotage régulier. Fixez des seuils réalistes : un SLA irréaliste pousse à contourner les règles au lieu d’améliorer la qualité.

Reprendre une application existante : les étapes

Cadrage et audit : inventaire des applications, des dépendances et des environnements, évaluation de la qualité du code, de la documentation et des tests.
Transfert de connaissances : ateliers avec l’équipe sortante, collecte et mise à jour de la documentation, accès aux environnements de développement, de test et de production.
Prise en main progressive : le prestataire observe d’abord, puis intervient sous supervision, puis prend la main. Cette montée en charge évite de découvrir les risques en production.
Exploitation et amélioration continue : traitement des demandes selon les SLA, reporting et plan de réduction de la dette technique.

La durée de la reprise dépend de la taille de l’application et de la qualité de la documentation. Les principaux risques sont la dépendance à une seule personne, l’absence de tests automatisés et des environnements impossibles à reproduire. Un audit initial permet de les mesurer avant de s’engager sur des niveaux de service.

La réversibilité : à prévoir dès la signature

La réversibilité garantit que vous pouvez changer de prestataire ou reprendre la maintenance en interne sans perdre la connaissance de l’application. Prévoyez dans le contrat :

la remise du code source, de son historique et des accès ;
une documentation à jour : architecture, procédures d’exploitation, base des incidents connus ;
une période d’accompagnement à la reprise, avec une durée et un prix définis ;
la propriété du code et des livrables, cédée par écrit.

La TMA nearshore depuis la Tunisie

Pour une entreprise française ou belge, confier une TMA à une équipe en Tunisie présente plusieurs avantages : un fuseau horaire compatible (0 à 1 heure de décalage avec la France), des équipes francophones, moins de trois heures de vol pour les rencontres sur site et des coûts plus prévisibles qu’un recrutement local. Hydatis combine une présence en France et un centre d’ingénierie en Tunisie. Vous pouvez découvrir notre approche du nearshore en Tunisie et notre offre de tierce maintenance applicative.

Trois points demandent de la rigueur :

L’organisation : un référent côté client, un responsable de service côté prestataire, un point hebdomadaire et un comité mensuel.
La sécurité : comptes nominatifs, accès limités au strict nécessaire, accords de confidentialité et traçabilité des actions.
Les données personnelles : les transferts hors de l’Union européenne exigent des garanties adaptées. Faites valider le dispositif par votre délégué à la protection des données.

Dix questions à poser avant de signer

Quel est le périmètre exact : applications, environnements, technologies, volumes ?
Quels niveaux de support assurez-vous, et sur quelles plages horaires ?
Quels SLA proposez-vous, et comment sont-ils mesurés et rapportés ?
Comment se déroule la reprise : durée, livrables, équipe mobilisée ?
Qui sont les personnes affectées, et quel est votre taux de rotation ?
Comment assurez-vous la continuité en cas d’absence d’un ingénieur ?
Quel modèle de facturation, et que se passe-t-il en cas de dépassement du périmètre ?
Quelles clauses de réversibilité et de propriété du code prévoyez-vous ?
Quelle politique de sécurité appliquez-vous : accès, postes de travail, sauvegardes, données personnelles ?
Pouvez-vous fournir des références sur des applications comparables ?

Questions fréquentes sur la TMA

Quelle est la différence entre TMA et maintenance interne ?

En maintenance interne, vos équipes assurent elles-mêmes le support et les corrections. En TMA, un prestataire s’en charge selon des niveaux de service contractuels, ce qui libère vos équipes pour la feuille de route et sécurise la continuité de service.

Combien coûte une TMA ?

Le coût dépend du périmètre, de la criticité, des technologies, des niveaux de service et du modèle de contrat. Demandez un chiffrage appuyé sur un audit de l’existant et méfiez-vous d’un prix donné sans périmètre précis.

Peut-on confier la TMA d’une application ancienne ou mal documentée ?

Oui. La reprise commence par un audit et une période d’observation. La maintenance s’accompagne ensuite d’une modernisation progressive, sans bascule risquée, pour réduire la dette technique.

Quelle est la durée d’un contrat de TMA ?

Les contrats sont souvent pluriannuels, avec une clause de réversibilité et la possibilité d’ajuster le périmètre. La durée doit laisser le temps d’amortir la reprise tout en préservant votre liberté de changer de prestataire.

La TMA convient-elle aux applications cloud et SaaS ?

Oui. Elle s’applique à toute application, qu’elle soit hébergée sur site ou dans le cloud, y compris à vos propres plateformes SaaS : correction des anomalies, mises à jour, évolutions et support.