L’essentiel : une TMA applicative sérieuse se reconnaît à quatre garanties écrites noir sur blanc : un délai d’intervention contractuel (GTI), une réversibilité sans frais, une documentation tenue à jour et un environnement de préproduction où chaque modification est testée avant d’atteindre vos utilisateurs. Chez PixiCode, ces garanties sont incluses dans tous nos paliers de maintenance, de 120 € HT par mois (Socle) à 190 € HT par mois (Critique), et vous restez propriétaire de 100 % du code.
Nous avons déjà détaillé ce qu’une TMA WordPress sérieuse doit garantir. Mais WordPress n’est qu’un cas particulier. Beaucoup d’entreprises dépendent d’un logiciel bien plus spécifique : une application métier en Java, une app mobile Flutter, une API en .NET ou en Python, développée un jour par un prestataire, un salarié parti depuis, ou une équipe qui n’existe plus. Ce logiciel tourne, l’activité repose dessus, et personne ne le maintient. Voici ce qu’une TMA applicative doit couvrir, et comment lire un contrat avant de le signer.
Une TMA applicative, c’est quoi exactement ?
TMA signifie tierce maintenance applicative : un tiers, en l’occurrence une agence, prend la responsabilité contractuelle de maintenir un logiciel qu’il n’a pas forcément développé. Cela recouvre trois familles d’interventions. La maintenance corrective traite les bugs et les incidents de production. La maintenance préventive met à jour les dépendances, les frameworks et les environnements d’exécution avant qu’ils ne deviennent des failles ou des impasses techniques. La maintenance évolutive, enfin, fait grandir le logiciel : un nouveau champ, un nouvel écran, une nouvelle intégration.
La nuance importante, c’est que la TMA applicative n’a rien d’un forfait générique. Maintenir une application Java d’entreprise, une app Flutter distribuée sur les stores ou une API Python n’exige ni les mêmes compétences, ni les mêmes outils, ni la même organisation. C’est précisément pour cela que la question « qui maintient votre logiciel ? » mérite une réponse plus précise que « notre hébergeur » ou « le développeur d’origine, s’il répond ».
Pourquoi un logiciel « fini » a quand même besoin d’une TMA
Un logiciel livré ne vit pas dans un monde figé. Les langages et frameworks publient des versions, les anciennes cessent d’être supportées, les bibliothèques accumulent des vulnérabilités connues et documentées publiquement. Une application mobile subit en plus la pression des stores : Apple et Google imposent régulièrement de nouvelles exigences techniques, et une app qui ne suit pas finit par être dépubliée ou par planter sur les derniers téléphones.
Un logiciel non maintenu ne tombe donc pas en panne d’un coup. Il se dégrade silencieusement : chaque mois qui passe sans mise à jour augmente le coût du rattrapage, jusqu’au jour où la question n’est plus « combien coûte la maintenance ? » mais « combien coûte la réécriture ? ». La TMA est exactement l’assurance contre ce scénario, à condition que le contrat contienne les bonnes garanties.
Les quatre garanties d’un contrat sérieux
Un engagement de délai, écrit. « On regarde ça rapidement » n’est pas un engagement. Un contrat sérieux définit des niveaux de service (SLA) avec une garantie de temps d’intervention (GTI) selon la criticité : un incident bloquant en production ne se traite pas dans le même délai qu’une demande d’évolution. Si le contrat ne distingue pas les deux, il ne vous protège de rien.
La réversibilité sans frais. Le code source, les accès, la documentation, les environnements : tout doit vous être restituable à tout moment, sans pénalité ni facturation de sortie. Chez PixiCode, c’est un principe non négociable : le client est propriétaire de 100 % du code, et la réversibilité est sans frais. Un prestataire qui rend votre départ coûteux a compris que la qualité de son service ne suffirait pas à vous retenir.
Une documentation tenue à jour. La documentation n’est pas un livrable de fin de projet, c’est un actif de maintenance. Chaque intervention doit la faire vivre : architecture, procédures de déploiement, décisions techniques. C’est elle qui rend la réversibilité réelle, et non théorique.
Un environnement de préproduction. Aucune modification, correctif compris, ne doit atteindre la production sans avoir été testée sur un environnement identique. C’est ce qui sépare une maintenance professionnelle d’une série de modifications à chaud, dont chacune peut casser ce que la précédente avait réparé.
Nos paliers : de 120 à 190 € HT par mois
Notre TMA applicative est structurée en paliers, de 120 € HT par mois pour le palier Socle à 190 € HT par mois pour le palier Critique, selon le niveau d’engagement de délai et l’étendue de la supervision. Dans tous les cas, les fondamentaux décrits plus haut sont inclus : engagement écrit, préproduction, documentation, réversibilité.
Pour les évolutions, les heures de développement démarrent à 58 € HT de l’heure, et l’hébergement supervisé dès 15 € HT par mois si vous souhaitez nous confier aussi l’infrastructure. Le forfait mensuel couvre la responsabilité et la veille ; les heures couvrent le travail effectif. Vous savez toujours ce que vous payez, et pourquoi.
La preuve par l’exemple : Finaxy Group
La TMA applicative n’est pas une ligne de plaquette : c’est notre quotidien. Pour Finaxy Group, nous assurons l’architecture Java et la tierce maintenance applicative d’un logiciel métier critique en production. Autrement dit, un logiciel dont l’entreprise dépend chaque jour, maintenu, supervisé et fait évoluer dans la durée.
Côté mobile, Carter Coaching illustre l’autre versant du métier : une application Flutter de gestion de club sportif, reprise en cours de développement à une précédente équipe. Nous avons d’abord consolidé l’existant, architecture, rôles et droits d’accès des joueurs, des coachs et des directeurs, puis enrichi l’application livraison après livraison, sans jamais repartir de zéro. Java côté serveur, Flutter côté mobile : la méthode est la même, seuls les outils changent.
Quand la TMA ne suffit plus
Il faut aussi savoir le dire : maintenir n’est pas toujours la bonne réponse. Quand les fondations d’un logiciel sont trop dégradées, une TMA revient à écoper un bateau qui prend l’eau plus vite qu’on ne vide. Un audit préalable tranche la question : stabiliser l’existant, reprendre le projet en profondeur, ou refondre. Nous avons décrit cette démarche dans notre article sur la reprise d’un projet mal parti, et notre équipe API et backend prend le relais quand la refonte s’impose. Un bon contrat de TMA prévoit d’ailleurs ce cas : il vous laisse libre de partir, documentation et code sous le bras.
Votre logiciel métier ou votre application tourne sans filet, ou vous doutez de ce que couvre votre contrat actuel ? Parlons-en : l’état des lieux est rapide, et vous saurez précisément où vous en êtes.
