MaintenanceExternalisationContratChoisir un prestataire
TMA (tierce maintenance applicative) : définition, contrat type et exemple concret
11 min de lecture
La tierce maintenance applicative (TMA) consiste à confier, par contrat, la maintenance d'une application à un prestataire extérieur. Celui-ci corrige les anomalies, applique les mises à jour, adapte l'application à son environnement et la fait évoluer, dans un périmètre, avec des niveaux de service et un prix fixés à l'avance. Ce qui distingue une TMA d'une maintenance « au fil de l'eau », c'est le contrat : il dit ce qui est couvert, en combien de temps, pour quel prix, et comment on en sort.
Notre article sur la maintenance d'une application métier décrit ce qui se passe techniquement après la mise en production. Celui-ci traite d'une autre question : comment externaliser cette maintenance, et quoi écrire dans le contrat pour qu'elle tienne ses promesses.
Définition : ce que recouvre la TMA
Le mot « tierce » désigne simplement le tiers : un prestataire qui n'est ni l'utilisateur de l'application, ni forcément celui qui l'a développée. La TMA est une forme d'externalisation. L'entreprise garde la maîtrise de ses besoins et de ses priorités ; le prestataire prend en charge l'exécution technique et s'engage sur des résultats mesurables.
On la rencontre dans trois situations :
- après un développement sur mesure, quand le prestataire qui a construit l'application en assure ensuite la maintenance ;
- lors d'un changement de prestataire, quand une application existante est reprise par une nouvelle équipe ;
- quand une équipe interne se recentre, et confie à l'extérieur les applications stables pour se consacrer aux projets.
TMA, infogérance, MCO, régie : ne pas tout confondre
Ces termes se chevauchent dans les offres commerciales. Les distinguer évite de signer un contrat qui ne couvre pas ce que vous croyez.
| Terme | Ce qui est pris en charge | Engagement du prestataire |
|---|---|---|
| Maintenance applicative | Le code de l'application, par une équipe interne ou externe | Variable selon l'organisation |
| TMA | Le code de l'application, externalisé par contrat | Résultats et délais mesurés |
| Infogérance | L'infrastructure : serveurs, réseau, sauvegardes, supervision | Disponibilité de l'infrastructure |
| MCO (maintien en condition opérationnelle) | L'ensemble du système, pour qu'il reste disponible | Souvent partagé entre TMA et infogérance |
| Régie | Des jours de développeurs, pilotés par le client | Moyens, pas résultat |
Le point de vigilance est la frontière entre TMA et infogérance. Quand l'application tombe, est-ce le code ou le serveur ? Si deux prestataires se partagent le système, le contrat doit dire lequel reçoit l'alerte, lequel diagnostique, et comment ils se coordonnent. Sinon, chacun renvoie la balle à l'autre pendant que vos équipes attendent.
Les types de maintenance couverts
La norme internationale de référence sur la maintenance logicielle, ISO/IEC/IEEE 14764:2022, distingue quatre catégories. Elles servent de base au découpage d'un contrat de TMA.
- La maintenance corrective répare un défaut constaté : un calcul faux, un écran qui se bloque, un export qui échoue.
- La maintenance préventive corrige un défaut latent avant qu'il ne provoque une panne : mise à jour d'une bibliothèque vulnérable, correction d'une fragilité repérée par la supervision.
- La maintenance adaptative fait suivre l'application aux changements de son environnement : nouvelle version du navigateur ou du système, API d'un partenaire qui change, nouvelle obligation réglementaire.
- La maintenance perfective, ou évolutive, améliore l'application ou lui ajoute des fonctions à la demande du métier.
La distinction a une conséquence financière. Les trois premières relèvent du fonctionnement normal de l'application et sont généralement incluses dans le forfait récurrent. Les évolutions dépendent de vos demandes, et se chiffrent à part. La frontière entre une correction et une évolution est la première source de litige en TMA : le contrat doit la définir avec des exemples.
Le cycle de vie d'une TMA
Un contrat de TMA ne démarre pas le jour de la signature par des corrections de bugs. Il suit en général quatre phases.
1. La prise de connaissance
Le prestataire récupère le code, les accès, la documentation et la base de données, puis audite l'application : sait-on la reconstruire et la déployer, quelles sont ses dépendances, ses fragilités, ses règles métier ? Quand l'application vient d'un autre prestataire, cette phase est décisive ; c'est le sujet de notre article sur l'audit d'une application avant reprise.
2. La transition
Le nouveau titulaire prend progressivement la main, parfois en parallèle de l'ancien. Les niveaux de service ne s'appliquent pas encore pleinement : c'est une période d'apprentissage, qui doit avoir une date de fin.
3. Le régime de croisière
Le prestataire traite les demandes selon les délais convenus, applique les mises à jour, livre les évolutions et rend compte de son activité à intervalles réguliers.
4. La réversibilité
À la fin du contrat, le prestataire transmet tout ce qui permet à un successeur, ou à votre équipe, de reprendre : code à jour, documentation, accès, procédures de déploiement, historique des demandes. Cette phase se négocie au moment de la signature, jamais au moment de la séparation. Notre article sur la réversibilité détaille ce qu'il faut pouvoir récupérer.
Ce que doit contenir un contrat de TMA
Voici les clauses à vérifier, dans l'ordre où elles posent problème quand elles manquent.
Le périmètre. Quelles applications, dans quelles versions, sur quels environnements (production, préproduction, recette) ? Quels utilisateurs peuvent ouvrir une demande ? Les interfaces avec d'autres logiciels sont-elles incluses ?
Les niveaux de gravité. Un blocage total de la production n'appelle pas la même réponse qu'une faute d'affichage. Trois ou quatre niveaux, définis par leur effet sur votre activité, avec un exemple pour chacun, suffisent.
Les délais, et lesquels. Un contrat sérieux distingue trois délais : le délai de prise en charge (quelqu'un a lu et qualifié la demande), le délai de contournement (l'activité peut reprendre, même de façon dégradée) et le délai de correction définitive. Un délai unique pour tout ne veut pas dire grand-chose. Précisez aussi les plages horaires couvertes : jours ouvrés, horaires étendus, astreinte.
La frontière entre correction et évolution. Qui décide qu'une demande est une anomalie ou une évolution ? Que se passe-t-il en cas de désaccord ? Une règle simple : est une anomalie ce qui contredit la documentation ou un comportement validé en recette.
Le prix. Ce qui est inclus dans le forfait, comment les évolutions sont chiffrées, comment le prix est révisé.
Les indicateurs et la gouvernance. Nombre de demandes ouvertes et fermées, respect des délais par niveau de gravité, état des mises à jour de sécurité. Un compte rendu mensuel et un comité trimestriel suffisent pour la plupart des applications métier d'une PME.
La sécurité et les données personnelles. Le prestataire de TMA accède presque toujours à des données personnelles : il agit alors comme sous-traitant au sens du RGPD, et le contrat doit comporter les clauses prévues à l'article 28. La CNIL publie un guide du sous-traitant qui en rappelle le contenu.
La propriété et les accès. Le dépôt de code, l'hébergement et les comptes des services tiers doivent rester à votre nom, ou vous être accessibles à tout moment. Les droits sur les développements réalisés pendant la TMA sont définis au cas par cas dans le contrat, comme pour le développement initial.
La réversibilité. Ce qui est transmis, dans quel délai, à quel prix, avec quelle assistance au successeur.
Ces clauses rejoignent celles d'un contrat de développement, que nous détaillons dans les clauses d'un contrat de développement logiciel.
Les modèles de prix d'une TMA
Il n'existe pas de tarif standard publié pour une TMA : le prix dépend de la taille de l'application, de son état, des délais exigés et des plages horaires couvertes. En revanche, les modèles de facturation sont peu nombreux, et ils ne répartissent pas le risque de la même façon.
| Modèle | Principe | Qui porte le risque | Adapté quand |
|---|---|---|---|
| Forfait récurrent | Un montant mensuel couvre la maintenance courante | Le prestataire, sur le périmètre défini | L'application est stable et bien connue |
| Unités d'œuvre | Un prix fixé par type de tâche (correctif, petit écran, intégration) | Partagé : prix unitaire fixe, volume variable | Les évolutions sont régulières et comparables |
| Volume de jours ou crédit d'heures | Un stock de temps consommé à la demande | Le client | Les demandes sont imprévisibles et petites |
| Régie | Des jours facturés au temps passé | Le client | Vous avez déjà une direction technique qui pilote |
| Abonnement global | Hébergement, maintenance et évolutions dans un même montant | Le prestataire | Vous voulez une application qui fonctionne, sans gérer la technique |
Le forfait combiné à des unités d'œuvre est une formule courante : la maintenance courante a un prix fixe, et chaque évolution a un prix connu avant d'être lancée. Pour comprendre pourquoi la régie laisse le risque au client, lisez notre article sur le forfait et la régie.
Exemple concret de TMA
Voici un exemple fictif, construit pour illustrer le fonctionnement d'un contrat. Une PME de distribution utilise une application web de gestion des commandes, développée il y a quelques années par une agence qui a cessé son activité. Une vingtaine de personnes s'en servent chaque jour.
Le périmètre. L'application de commandes, son interface avec le logiciel de comptabilité, et le portail où les clients suivent leurs livraisons. L'hébergement reste chez un infogéreur distinct.
Les niveaux de gravité.
| Niveau | Exemple | Prise en charge | Contournement |
|---|---|---|---|
| Bloquant | Plus aucune commande ne peut être saisie | Dans l'heure ouvrée | Dans la journée |
| Majeur | L'export vers la comptabilité échoue | Dans la demi-journée | Sous deux jours ouvrés |
| Mineur | Un libellé erroné sur le portail client | Sous deux jours ouvrés | Livraison suivante |
Ces délais sont donnés pour l'exemple : ils se négocient selon l'importance de l'application pour votre activité, et chaque engagement plus court a un prix.
Le prix. Un forfait mensuel couvre la correction des anomalies, les mises à jour de sécurité et l'adaptation aux changements d'environnement. Les évolutions sont chiffrées en unités d'œuvre, avec un devis validé avant chaque lancement.
Le déroulé d'une demande. Un lundi, l'export comptable échoue. La responsable administrative ouvre un ticket, classé « majeur ». Le prestataire le prend en charge dans la matinée, constate que le logiciel de comptabilité a changé le format attendu, livre un contournement le soir même, puis une correction définitive testée en préproduction. Comme la cause est un changement d'environnement, c'est de la maintenance adaptative : elle entre dans le forfait, sans devis.
La gouvernance. Un compte rendu chaque mois (demandes, délais tenus, mises à jour appliquées), un point trimestriel pour prioriser les évolutions.
Quand la TMA n'est pas la bonne réponse
- L'application est en fin de vie. Si chaque correction en casse une autre et que la technologie n'est plus maintenue, payer une TMA revient à financer le déclin. Il faut d'abord décider d'une refonte.
- Le produit change chaque semaine. Un logiciel au cœur de votre offre, qui évolue en continu, relève plutôt d'une équipe produit dédiée que d'un contrat de maintenance.
- Personne ne peut piloter côté client. Une TMA externalise l'exécution, pas la décision. Il faut quelqu'un pour prioriser les demandes et valider les livraisons.
- Le projet a été abandonné en cours de route. Une application inachevée ne se maintient pas, elle se reprend : c'est le sujet de notre article sur la reprise d'un projet logiciel abandonné.
Les erreurs fréquentes
- Signer sans phase de prise de connaissance. Le prestataire s'engage sur des délais pour une application qu'il ne connaît pas, puis invoque l'état du code à chaque retard.
- Confondre délai de prise en charge et délai de correction. « Quatre heures » peut signifier qu'un ticket a été lu, pas que le problème est réglé.
- Laisser les accès au nom du prestataire. Le jour du changement, vous découvrez que le dépôt de code et l'hébergement ne vous appartiennent pas.
- Oublier la maintenance préventive. Invisible pour les utilisateurs, elle est la première sacrifiée quand le forfait est trop serré, et c'est elle qui évite les incidents graves.
- Ne jamais tester la réversibilité. Un contrat peut promettre la transmission de la documentation ; vérifiez chaque année qu'elle existe et qu'elle est à jour.
La position de LPR Studio
Nous ne vendons pas de régie, et nous ne proposons pas de TMA en jours facturés. Pour les applications que nous développons, la maintenance fait partie du produit : dans la formule abonnement, l'hébergement, la maintenance et les évolutions sont couverts par un montant mensuel, et nous restons éditeur et exploitant de l'application, avec des droits définis au cas par cas dans le contrat. Au forfait, le contrat de maintenance se négocie en même temps que le développement, pas une fois l'application livrée.
Si votre application actuelle arrive au bout de ce qu'une maintenance peut faire, la première étape est de voir à quoi ressemblerait la suite : nous construisons un prototype visuel gratuit, présenté en visio sous 5 jours ouvrés, avant tout engagement.