TMA informatique : ce que couvre vraiment un contrat de maintenance

Votre application fonctionne. Elle a été livrée il y a deux ans, elle rend service tous les jours, et personne ne s’en occupe vraiment. Un bug apparaît de temps en temps, quelqu’un le contourne, la vie continue. Puis un matin plus rien ne répond, et vous découvrez que le prestataire qui l’a construite ne fait plus ce métier.

C’est exactement le scénario que la TMA existe pour éviter. Voici ce que recouvre ce sigle, ce qu’un contrat doit contenir pour être utile, et comment se passe une reprise quand le code vient de quelqu’un d’autre.

TMA : la définition, sans le jargon

TMA veut dire tierce maintenance applicative. « Applicative » parce qu’il s’agit de vos applications, pas de vos serveurs ni de vos postes de travail. « Tierce » parce que c’est confié à un prestataire extérieur, distinct de vos équipes et parfois distinct de celui qui a écrit le logiciel au départ.

Concrètement, un contrat de TMA confie à quelqu’un la responsabilité qu’un logiciel déjà en production continue de fonctionner et continue d’évoluer. Ce n’est pas de l’infogérance, qui s’occupe de l’infrastructure et du réseau. Ce n’est pas non plus un nouveau projet de développement. C’est le travail d’entretien qui commence le jour où la mise en ligne est faite.

On distingue traditionnellement quatre types d’intervention, et il est utile de savoir lesquels votre contrat couvre :

• Corrective : réparer ce qui ne fonctionne pas. Un bouton qui ne répond plus, un export qui produit un fichier vide, un calcul qui donne un mauvais résultat.
• Préventive : agir avant la panne. Mises à jour de sécurité des bibliothèques, surveillance des performances, sauvegardes vérifiées et non simplement programmées.
• Évolutive : ajouter ou modifier des fonctionnalités. Un nouveau champ, un nouvel export, un changement de règle métier parce que la réglementation a bougé.
• Adaptative : suivre l’environnement. Une nouvelle version de navigateur, un partenaire qui change son API, un système mobile qui impose un nouveau format.

Beaucoup de contrats ne couvrent que le correctif et vendent le reste au coup par coup. Ce n’est pas illégitime, mais il vaut mieux le savoir avant de signer qu’au moment de recevoir le devis d’une évolution que vous pensiez incluse.

Ce qu’un contrat de TMA doit dire noir sur blanc

Un contrat de maintenance applicative qui tient en une page et parle de « support et assistance » ne vous protège de rien. Quatre éléments méritent d’être écrits précisément.

Le périmètre applicatif. Quelles applications, quels modules, quels environnements. Si votre outil comporte une partie web et une application mobile, dites si les deux sont couvertes. Si un module a été développé par un autre prestataire, dites ce qu’il advient de lui.

Les délais d’intervention, par niveau de gravité. C’est le cœur du sujet. Un bug bloquant qui empêche vos équipes de facturer n’appelle pas le même délai qu’une faute d’orthographe dans un libellé. Une grille à trois niveaux suffit dans la plupart des cas : bloquant, gênant, mineur, avec pour chacun un délai de prise en charge et un délai de résolution. Attention à la différence entre les deux : « prise en charge sous 4 heures » signifie qu’on vous répond, pas que c’est réparé.

Le volume inclus. La maintenance évolutive se compte généralement en jours ou en heures par mois. Vérifiez ce qui se passe quand vous ne les consommez pas : reportés au mois suivant, perdus, plafonnés au trimestre. Vérifiez aussi le tarif au-delà du forfait.

La réversibilité. C’est la clause qu’on regarde le moins et qu’on regrette le plus. Que se passe-t-il si vous partez ? Le code source vous est-il livré, avec sa documentation et ses accès ? Sous quel délai ? Un contrat qui rend le départ compliqué est un contrat qui compte sur votre inertie plutôt que sur la qualité de son service.

Comment se facture la TMA

Trois modèles cohabitent, chacun avec sa logique.

Le forfait mensuel couvre un périmètre défini pour un montant fixe. C’est le plus lisible pour votre budget et le plus confortable quand l’application est stable. Il se situe souvent entre 5 et 15 % du coût de développement initial sur une année, selon la criticité de l’outil et les délais promis.

Les jours consommés fonctionnent sur un stock acheté d’avance, décompté au fil des interventions. Adapté quand les besoins sont irréguliers, moins prévisible pour la trésorerie.

La régie au fil de l’eau facture ce qui est fait, quand c’est fait. Souple, mais aucun engagement de délai n’est possible : votre demande passe après celles des clients sous contrat.

Un repère utile pour arbitrer : si l’arrêt de votre application empêche votre activité de tourner ne serait-ce qu’une demi-journée, prenez un forfait avec des délais écrits. Le surcoût par rapport aux jours consommés est le prix de l’assurance que quelqu’un est tenu de décrocher.

Reprendre une application développée par quelqu’un d’autre

C’est la situation la plus fréquente quand on nous appelle. Le prestataire d’origine a disparu, a changé de métier, ou la relation s’est dégradée. Bonne nouvelle : reprendre du code existant est un exercice courant. Il demande simplement de ne pas brûler l’étape du diagnostic.

On commence par un audit. Une à deux semaines pour lire le code, cartographier les fonctionnalités réellement utilisées, mesurer la dette technique et vérifier l’état des dépendances. Une bibliothèque abandonnée depuis quatre ans, ou une version de langage qui ne reçoit plus de correctifs de sécurité, change complètement le tableau.

On vous dit franchement ce qui est récupérable. Parfois le code est correct et mérite juste d’être mis à jour. Parfois une partie est saine et une autre doit être réécrite. Parfois, plus rarement, tout reconstruire coûte moins cher que maintenir l’existant, et il faut avoir le courage de le dire même quand ce n’est pas ce que vous espériez entendre.

On vérifie que vous possédez ce qu’il faut. Code source, accès aux serveurs, noms de domaine, comptes des services tiers. Une reprise se bloque plus souvent sur un accès manquant que sur une difficulté technique. Si le prestataire précédent détient encore quelque chose, c’est le moment de le récupérer, pendant que la relation permet encore de le demander.

On stabilise avant d’améliorer. Les premières semaines servent à remettre la sécurité à niveau, à restaurer des sauvegardes fiables et à corriger ce qui gêne au quotidien. Les évolutions viennent ensuite, une fois le terrain sûr.

Les trois questions à poser avant de signer

Si vous ne deviez en retenir que trois, prenez celles-ci.

Que se passe-t-il si mon application tombe un vendredi à 17 h ? La réponse vous dira si les délais annoncés valent en dehors des heures ouvrées, et si quelqu’un est réellement d’astreinte.

Qui possède le code, et comment je le récupère ? Une réponse hésitante est déjà une réponse.

Qu’est-ce qui n’est pas inclus ? Un prestataire qui répond précisément à cette question sait ce qu’il vend. Celui qui répond « on verra au cas par cas » vous prépare des factures que vous n’aviez pas anticipées.

La TMA n’est pas la partie excitante d’un projet. C’est pourtant elle qui décide si l’outil dans lequel vous avez investi sera encore utile dans cinq ans, ou s’il aura été remplacé faute d’avoir été entretenu.

Si vous avez une application en production dont plus personne ne s’occupe, on peut l’auditer et en reprendre la maintenance, même si nous ne l’avons pas écrite.