TMA : ce que vous achetez vraiment quand vous signez un contrat de tierce maintenance applicative
La TMA n'est pas de la sous-traitance de maintenance. C'est un engagement de service avec un périmètre, une gouvernance et une logique de partenariat à long terme. Ce que la plupart des contrats ne disent pas.
Donatien Lefranc
Fondateur & Président, Leando
Ce que la plupart des dirigeants croient acheter en signant une TMA
Quand une PME signe un contrat de tierce maintenance applicative, elle pense généralement acheter trois choses : quelqu'un qui répare quand quelque chose casse, quelqu'un qui répond quand elle appelle, et un prix prévisible chaque mois. Ces attentes sont légitimes. Elles décrivent pourtant une vision très partielle de ce qu'une TMA peut et devrait être.
Une TMA bien structurée fait bien plus que corriger des bugs. Elle maintient la connaissance du système centralisée et documentée. Elle identifie la dette technique avant qu'elle ne devienne un problème de production. Elle fait évoluer le logiciel en suivant la feuille de route métier, pas en répondant à des urgences ponctuelles. Et elle s'engage sur des indicateurs mesurables, pas sur de la bonne volonté.
La confusion vient souvent de là : en achetant une TMA, certains dirigeants pensent acheter un prestataire disponible. Ils achètent en réalité un modèle d'organisation pour la maintenance à long terme. Les deux ne sont pas la même chose.
Ce que le dirigeant attend
« Quelqu'un qui corrige les bugs, disponible quand j'appelle, pour un prix mensuel fixe »
Ce que le contrat garantit souvent
Un volume de jours ou de tickets, avec des délais de réponse sur incidents P1/P2/P3
Ce qui détermine vraiment la qualité
La gouvernance, la documentation du système et la continuité de la connaissance
TMA définition : ce que le sigle recouvre vraiment
La tierce maintenance applicative désigne le fait de confier à un prestataire externe (le « tiers ») la maintenance d'un ou plusieurs logiciels métier. Le terme recouvre trois familles d'activités : la maintenance corrective (corriger ce qui ne fonctionne pas), la maintenance évolutive (faire évoluer le logiciel selon les besoins métier), et la maintenance adaptative (maintenir la compatibilité avec les évolutions d'infrastructure, de réglementation ou de dépendances tierces).
Ce qui distingue une TMA d'une prestation ponctuelle, c'est la continuité. Un prestataire TMA s'engage dans la durée sur un système qu'il apprend à connaître. Cette connaissance accumulée est ce qui lui permet d'intervenir rapidement, de prédire les zones à risque, et de faire évoluer le logiciel sans produire de régressions. C'est aussi ce qui rend le changement de prestataire TMA coûteux : une partie de la valeur réside dans la connaissance du système, pas dans les compétences techniques génériques.
La distinction avec la régie (un développeur facturé à la journée) est importante. En régie, vous achetez du temps. En TMA, vous achetez un service. La différence se ressent quand quelque chose casse à 17h le vendredi : en régie, c'est une question contractuelle. En TMA, c'est l'objet même du contrat.
Les 3 composantes d'une TMA qui tient dans le temps
Une TMA durable repose sur trois piliers, et l'absence de l'un d'eux finit toujours par se payer. Les contrats qui déçoivent ont en général négligé le troisième.
Le périmètre applicatif documenté
Le prestataire TMA doit connaître le système qu'il maintient : architecture, dépendances, règles métier encodées, zones sensibles. Sans documentation, chaque intervention est une découverte. Le premier signal d'une TMA mal initiée : le prestataire ne peut pas donner d'estimation sans audit à chaque nouvelle demande.
La gouvernance partagée
Un point de suivi mensuel minimum, un processus de priorisation des demandes, des indicateurs de performance suivis par les deux parties. La gouvernance n'est pas de la bureaucratie : c'est ce qui permet au dirigeant de garder la main sur le système sans avoir à descendre dans le technique. Sans gouvernance, la TMA glisse progressivement vers de la régie déguisée.
La feuille de route évolutive
La maintenance corrective est non-négociable. La maintenance évolutive, elle, se priorise. Une TMA sans vision à 12 mois finit par traiter les urgences du moment et ignorer les investissements qui éviteraient les urgences futures. La feuille de route partagée est ce qui transforme une TMA en partenariat stratégique plutôt qu'en pompier à loyer mensuel.
« Devenir comme un partenaire, non pas avec une solution “billet en tête”, mais vraiment avec une volonté de résoudre des problèmes dans un contexte et dans une perspective de comment ça va s'inscrire dans le temps. »
— Donatien Lefranc, fondateur de Leando
Pourquoi la TMA sans gouvernance se dégrade en silence
La dégradation d'une TMA est rarement visible au démarrage. Elle s'installe progressivement, sur 12 à 24 mois, et les signaux d'alerte sont souvent interprétés comme des problèmes ponctuels plutôt que comme des symptômes d'un dysfonctionnement structurel.
Le schéma typique : les interventions correctives sont traitées, mais les évolutions s'accumulent dans un backlog sans priorisation. Le prestataire traite ce qui remonte, pas ce qui est prioritaire pour le métier. La connaissance du système reste dans les têtes des personnes qui travaillent dessus, pas dans des documents. Les réunions de suivi n'ont jamais lieu régulièrement. Et quand un problème sérieux survient, il faut deux semaines pour comprendre ce qui a changé.
4 signaux d'une TMA en dérive
- Les demandes d'évolution attendent plus de 6 semaines sans retour de priorisation
- Le prestataire demande un temps d'analyse à chaque nouvelle demande, même sur des sujets récurrents
- Il n'existe pas de document décrivant l'architecture actuelle du système
- Personne, ni côté client ni côté prestataire, ne peut dire ce qui a changé dans le système au cours des 3 derniers mois
Ce que ces signaux révèlent n'est pas une incompétence du prestataire. C'est souvent l'absence d'un cadre qui lui permette de travailler autrement. La gouvernance n'est pas une contrainte pour le prestataire. C'est ce qui lui permet de se concentrer sur ce qui apporte de la valeur plutôt que sur ce qui est urgent.
« Il y a des entreprises qui veulent aller trop vite, d'autres qui voudraient aller plus vite mais n'y arrivent pas, d'autres qui voudraient aller plus doucement sans se rendre compte à quel point elles auraient des gains de productivité à aller chercher. On est aussi là pour rythmer, cadencer dans une temporalité saine. »
— Donatien Lefranc, fondateur de Leando
Comment structurer une TMA qui dure
La mise en place d'une TMA structurée suit une logique en 4 temps. Chaque étape conditionne la suivante et l'absence de l'une d'elles crée une dette de gouvernance qui se paiera plus tard.
Audit d'entrée
Avant de s'engager sur des délais, le prestataire doit connaître le système. Cet audit couvre l'architecture, les dépendances, les zones de dette technique connues et les règles métier encodées. Il prend généralement 2 à 5 jours selon la complexité du système. Un prestataire qui s'engage sans audit est soit très expérimenté sur ce type de stack, soit imprudent.
Définition du périmètre et des niveaux de service
Quels modules sont couverts, quelle classification des incidents (P1 bloquant, P2 important, P3 standard), quels délais de traitement par niveau, quel volume mensuel inclus et que se passe-t-il en dépassement. Ce périmètre doit être écrit, pas verbal.
Mise en place de la gouvernance
Point mensuel minimum sur les priorités en cours et à venir, reporting des interventions réalisées, tableau de bord partagé des tickets ouverts/fermés, process de validation des évolutions. La gouvernance légère prend 2 heures par mois. Elle évite des incompréhensions qui en coûtent 20.
Feuille de route évolutive sur 12 mois
Quelles évolutions fonctionnelles sont prévues, dans quel ordre, avec quel impact estimé sur le budget TMA. Cette feuille de route est révisée tous les trimestres. Elle transforme la TMA en instrument de pilotage stratégique.
Cette structure ne garantit pas que tout se passera bien. Elle garantit que quand quelque chose se passe mal, les deux parties savent comment l'identifier, le prioriser et le traiter. C'est précisément la différence entre un partenariat et une relation transactionnelle.
Pour comprendre comment la MCO s'articule avec la TMA, notre article sur la maintenance en condition opérationnelle détaille la logique de planification sur 12 à 18 mois.
TMA et vibe coding : pourquoi la gouvernance devient non-négociable
Depuis 2024, une proportion croissante de logiciels PME contient du code généré par IA sans revue de qualité systématique. Le vibe coding produit vite. Il produit aussi des bases de code difficilement maintenables, sans tests, avec des dépendances opaques et des règles métier implicites.
Pour une TMA, c'est une rupture de contexte. Un prestataire qui prenait en charge un logiciel développé avec une méthodologie classique disposait de conventions prévisibles. Un logiciel développé au vibe coding peut avoir une architecture incohérente, des dépendances non documentées et des patterns qui changent d'un module à l'autre selon le modèle IA qui a généré le code.
Cela ne rend pas le vibe coding inutilisable. Cela rend l'audit d'entrée indispensable et la gouvernance technique active encore plus critique. Un prestataire TMA sur un logiciel vibe-codé qui ne fait pas de revue de code régulière accumule une dette technique à une vitesse que personne ne mesure.
| Ce que l'IA peut accélérer dans une TMA | Ce que l'IA ne remplace pas |
|---|---|
| Rédaction de tests de non-régression | Décision de priorisation des évolutions |
| Détection d'anomalies dans les logs | Évaluation de l'impact métier d'un bug |
| Suggestion de refactoring sur du code répétitif | Validation que la correction correspond au besoin |
| Documentation automatique de fonctions | Gouvernance et arbitrages stratégiques |
| Revue de dépendances obsolètes | Relation de confiance avec le client |
Notre article sur le vibe coding et la dette technique détaille les mécanismes par lesquels un logiciel développé à l'IA peut se retrouver en maintenance d'urgence 18 mois après sa livraison.
Cas réel : d'un pool de freelances à une TMA structurée
Voici un cas concret qui illustre ce que la transition d'un pool de freelances vers une TMA structurée change concrètement.
ETI industrielle, 120 salariés, logiciel de gestion sur mesure
Cette ETI avait développé un logiciel de gestion métier sur mesure 4 ans plus tôt. La maintenance était assurée par un pool de 3 freelances sollicités ponctuellement selon les disponibilités. En apparence, le système fonctionnait. En réalité, la situation était fragile : chaque freelance connaissait une partie du système, pas sa globalité. La documentation était absente. Quand l'un d'eux devenait indisponible, les délais d'intervention triplaient.
En 2025, une mise à jour d'un framework tiers a cassé 3 modules critiques simultanément. La remise en service a pris 9 jours. Non par manque de compétences, mais parce que personne ne disposait d'une vision globale du système et de ses interdépendances. Le coût direct de l'interruption dépassait le budget TMA annuel.
La transition vers une TMA structurée a commencé par un audit de 4 jours. Le résultat : une cartographie complète de l'architecture, 27 points de dette technique identifiés, et un périmètre de responsabilité clairement défini. Le premier point mensuel de gouvernance a eu lieu 3 semaines après le démarrage du contrat. 14 mois plus tard, le dernier incident de production majeur remonte à 8 mois.
« On n'est pas là pour délivrer du code. Notre valeur, c'est la capacité à poser les bonnes questions, à structurer la manière d'avancer et à prendre les bonnes décisions. »
— Donatien Lefranc, fondateur de Leando
Ce cas illustre un principe que beaucoup de dirigeants découvrent trop tard : le coût d'une TMA mal structurée n'est pas le budget mensuel. C'est le coût d'une interruption critique quand la connaissance du système est dispersée entre des individus qui ne sont pas disponibles en même temps.
Pour aller plus loin sur la question du choix du bon prestataire pour votre SI, notre article sur les erreurs classiques du développement sur mesure détaille les pièges à éviter dès la mise en production.
Pour aller plus loin
MCO informatique : guide complet
Planifier la maintenance sur 12-18 mois pour éviter les urgences.
Moderniser le SI d'une PME : méthode et guide
Étapes, pièges et méthode pour une modernisation sans rupture.
Vibe coding et dette technique
Pourquoi le code IA sans gouvernance crée des crises en production.
Logiciel sur mesure vs SaaS : le vrai arbitrage
Quand le sur mesure est justifié et quand il ne l'est pas.
Les questions qu'on nous pose le plus souvent sur la TMA
Questions fréquentes sur la TMA
La MCO (Maintenance en Condition Opérationnelle) est un périmètre d'activités : corriger les bugs, faire évoluer le logiciel, adapter aux changements d'environnement. La TMA est un mode d'organisation : vous externalisez ces activités à un prestataire tiers. On peut faire de la MCO en interne ou via TMA. La TMA est un contrat, la MCO est ce qu'il contient. Signer une TMA sans avoir défini votre périmètre MCO, c'est acheter un service sans savoir ce qu'il couvre.
Passez à l'action
Votre TMA couvre ce que vous pensez qu'elle couvre ?
Leando audite votre contrat TMA existant, votre base de code et votre gouvernance actuelle. Vous repartez avec un diagnostic clair et des recommandations concrètes.
Demander un audit gratuit