La TMA informatique, ou tierce maintenance applicative, consiste à confier à un prestataire externe le maintien d’une application en état de fonctionner et de rester sécurisée : correction des anomalies, évolutions fonctionnelles, adaptations techniques. Pour une application métier dont l’arrêt bloque la facturation, la production ou la relation client, c’est la différence entre une maintenance applicative subie et une maintenance maîtrisée.
Voici la définition de la TMA telle que la fixe le cadre de référence, la différence entre maintenance corrective et maintenance évolutive, ce qu’un contrat TMA doit prévoir et ce que coûte ce type de prestation.
Définition de la TMA : ce que recouvre la tierce maintenance applicative
La tierce maintenance applicative (TMA) désigne les prestations qui consistent à conserver un système d’information dans un état lui permettant de remplir sa fonction. Ces prestations s’exécutent à titre préventif ou correctif, et peuvent aussi inclure des évolutions ou des adaptations des logiciels. C’est la définition que donne l’article 38 du CCAG TIC, le cahier des clauses administratives générales des marchés publics de techniques de l’information et de la communication, approuvé par l’arrêté du 30 mars 2021.
Ce texte vise les marchés publics et n’est pas conçu pour les achats des acteurs privés. Il reste pourtant un repère utile pour rédiger un contrat, parce qu’il pose des définitions précises et partagées des différents types de maintenance.
Dans la pratique, la TMA porte sur le code et le fonctionnement de l’application. L’infogérance, elle, porte sur l’infrastructure : serveurs, réseau, postes de travail.
Les quatre types de maintenance
Le CCAG TIC distingue quatre types de maintenance : préventive, corrective, évolutive et adaptative. Chacune répond à un besoin différent, comme le montre le tableau ci-dessous.
| Type | Objectif | Exemple |
|---|---|---|
| Corrective | Corriger les anomalies | Un calcul de tarif renvoie un résultat faux |
| Préventive | Éviter la survenance d’anomalies | Corriger une faille connue d’une dépendance avant qu’elle soit exploitée |
| Évolutive | Intégrer de nouvelles fonctions, améliorer le fonctionnement, prendre en compte une nouvelle réglementation | Ajouter un export comptable |
| Adaptative | Absorber un changement d’environnement technique : système, base de données, interfaces, bibliothèques | Montée de version de PHP ou du framework, nouvelle API partenaire |
La maintenance corrective est celle que l’on voit le plus : un utilisateur signale un bug, le prestataire le qualifie, le corrige et le livre. La maintenance évolutive répond à un autre rythme. Elle sert à faire suivre l’application au même pas que l’activité, qu’il s’agisse d’une nouvelle fonction ou d’une obligation réglementaire.
La maintenance préventive et adaptative ne produit rien de visible pour les utilisateurs. C’est pourtant elle qui évite qu’une application glisse vers un état legacy où plus personne n’ose intervenir.
TMA, infogérance, support : ne pas confondre
Ces trois services se côtoient souvent dans un même projet, mais ils ne répondent pas à la même question.
| TMA | Infogérance | Support utilisateur | |
|---|---|---|---|
| Périmètre | Le code et le fonctionnement de l’application | Serveurs, réseau, sauvegardes | Assistance aux utilisateurs |
| Question type | « Pourquoi ce calcul est faux ? » | « Pourquoi le serveur ne répond plus ? » | « Comment j’exporte ce fichier ? » |
Le CCAG TIC prévoit d’ailleurs que des prestations de maintenance de matériel puissent être incluses dans un marché de TMA. Les deux se combinent donc, à condition que le contrat le précise noir sur blanc. Pour la partie infrastructure, notre page infogérance serveur détaille ce périmètre.
Quand passer en TMA
Certains signaux reviennent presque toujours avant la décision :
- Une seule personne sait intervenir sur l’application. C’est le risque de dépendance que nous détaillons dans Votre applicatif métier tient sur un seul développeur : ce que ça coûte vraiment.
- Le développeur historique s’en va ou parle de partir. La transmission de connaissances doit avoir lieu avant son départ, pas après.
- La documentation est absente ou obsolète.
- Il n’existe aucun test automatisé ni monitoring, et le déploiement ne fonctionne que si une personne précise s’en charge.
- L’application est critique : son arrêt provoque un arrêt d’activité partiel ou total, sur les commandes, les stocks, la facturation ou la logistique par exemple.
Si plusieurs de ces signaux sont réunis, un diagnostic de criticité permet d’objectiver le risque avant qu’il ne se transforme en incident. Notre article sur les signaux d’alerte applicative prolonge ce point.
Besoin d’un audit ?
Chez Mink, nous commençons par un audit technique du code existant, puis nous vous proposons une offre de maintenance sur mesure.
Ce que doit contenir un contrat de TMA
Un contrat de TMA solide tient en cinq points.
Le périmètre. Il liste les applications couvertes, les environnements (production, recette) et les interfaces avec les autres outils. Ce qui n’est pas écrit n’est pas maintenu.
Les niveaux de service (SLA). Ils fixent les délais d’intervention, la plage horaire de prise en charge et la priorité accordée aux incidents, selon l’impact réel de chaque outil sur l’activité. Chez Mink, nous définissons ces niveaux avec chaque client : une application métier critique n’appelle pas la même urgence qu’un site institutionnel.
Le volume d’évolutions. Il se fixe en jours par mois ou en forfait, avec une règle claire pour les dépassements. C’est ici que se joue le choix entre forfait et régie, que nous détaillons dans Régie vs forfait.
La réversibilité. Documentation, accès au code et aux environnements, modalités de transfert en fin de contrat : tout doit être prévu dès la signature. Le sujet a son propre article, La clause de réversibilité : ce qu’on signe sans lire, et qui coûte cher trois ans plus tard.
Le reporting. Un point mensuel sur les incidents, les livraisons et l’état de la dette technique évite que la TMA devienne une boîte noire.
La reprise : l’étape à sécuriser en premier
Reprendre une application écrite par quelqu’un d’autre demande de la méthode. Nous commençons systématiquement par un audit technique du code existant : architecture, dépendances, versions, points de fragilité. Il permet de chiffrer le risque réel avant tout engagement. Pour un regard centré sur la sécurité, nous proposons aussi un audit de sécurité applicative, et notre article sur l’audit d’une application PHP en production détaille ce qu’il révèle.
La reprise se poursuit ensuite avec un environnement de test qui reproduit la production et un plan de résorption de la dette technique priorisé, sans interrompre le service. Notre article sur le changement de prestataire de maintenance détaille cette méthode semaine par semaine.
Combien coûte une TMA ?
Le prix dépend de la criticité de l’application, de sa taille, de son état technique et du volume d’évolutions attendu. C’est pour cette raison que nous ne publions pas de grille unique : sur notre page maintenance, nous indiquons qu’un contrat de maintenance de site web démarre à quelques centaines d’euros par mois pour un site standard, et que pour une application métier complexe, le tarif est adapté à la criticité, avec une offre sur mesure après audit de l’existant.
Le choix entre forfait et régie dépend de la maturité de votre besoin. Le forfait convient à un périmètre stable et bien défini, la régie à un besoin qui évolue encore. Notre comparatif Régie vs forfait détaille les deux modes.
Un exemple tiré de notre pratique : un acteur du secteur logistique avait deux applications métier critiques, utilisées par plus de 1 800 personnes par mois, qui reposaient sur un seul développeur interne, sans documentation ni tests. L’audit a permis de cartographier le code, d’identifier les dépendances critiques et de poser les bases d’une mission de TMA structurée. Le développeur interne a été repositionné comme référent métier, et la dette technique a été réduite progressivement sur 18 mois. Le détail figure dans notre article sur la dépendance à un développeur unique.
Reprendre votre application en TMA
Chez Mink, nous intervenons sur des applications métier tournant sur Symfony ou Laravel. Nous commençons par un audit du code existant, et si le code présente des problèmes structurels, nous vous le disons clairement. Si votre application a été conçue chez nous, la même équipe en assure ensuite la maintenance : c’est le principe de notre offre d’application métier sur-mesure.
Faites le point sur l’application qui vous inquiète le plus.
Réservons 30 minutes pour évaluer la situation et les options de reprise.
