La tierce maintenance applicative maintient en vie une application métier après sa mise en production, quand l'équipe qui l'a construite ne s'en occupe plus. C'est aussi le contrat que l'on signe le plus vite et que l'on relit le moins souvent. En 2026, deux mouvements le rendent pourtant central : la vague de fins de support des socles techniques, et des obligations européennes qui donnent une valeur juridique à la notion de durée de support.

Ce que recouvre vraiment la tierce maintenance applicative

Le sigle TMA recouvre quatre prestations très différentes, et la plupart des litiges naissent de leur confusion. Un contrat lisible les nomme séparément et affecte à chacune un forfait ou un volume distinct.

  • Le correctif : réparer ce qui ne fonctionne pas comme spécifié. C'est la seule prestation que tout le monde a en tête, et souvent la seule réellement couverte.
  • L'adaptatif : faire suivre l'application quand son environnement bouge, sans que sa valeur métier change. Montée de version du langage, nouveau système mobile, changement d'API chez un tiers, rotation d'un certificat.
  • L'évolutif : ajouter ou modifier des fonctions. Il n'a rien à faire dans un forfait au poids, il se pilote par enveloppe et par priorisation.
  • Le préventif : mise à jour des dépendances, vérification des restaurations, revue des droits. Invisible tant qu'il est fait, très visible sinon.

Un contrat qui ne parle que de correctif produit toujours le même scénario : l'application fonctionne, personne ne la met à jour, et trois ans plus tard le devis de remise à niveau dépasse le coût cumulé de la maintenance évitée.

Pourquoi la part adaptative n'est plus optionnelle

Les socles techniques ont des dates de fin de vie publiques, et 2026 en concentre plusieurs. Node.js 20 est sorti du support le 30 avril 2026 : les vulnérabilités découvertes depuis ne reçoivent plus de correctif officiel. PHP 8.2 s'arrête le 31 décembre 2026, après une phase de support de sécurité entamée fin 2024. Ces dates ne se négocient pas et ne dépendent pas de votre prestataire.

Le cadre réglementaire pousse dans le même sens. Le règlement européen sur la cyberrésilience impose depuis le 11 septembre 2026 le signalement des vulnérabilités activement exploitées, et l'ensemble de ses obligations devient contraignant le 11 décembre 2027 pour les produits numériques mis sur le marché européen, avec une période de support d'au moins cinq ans sauf durée de vie plus courte. Une application développée pour votre seul usage interne n'est généralement pas concernée, mais les briques que vous consommez le sont, et vos clients répercutent déjà la question dans leurs consultations.

Traduction contractuelle : votre contrat doit dire qui surveille les fins de support, à quelle échéance il vous alerte et qui paie la montée de version. Sans cette clause, la réponse par défaut est : personne, jamais, vous.

Les huit clauses à verrouiller

  1. Le périmètre nommé. Liste des applications, des modules, des intégrations et des environnements couverts. Ce qui n'est pas écrit n'est pas couvert.
  2. La qualification des demandes. Qui décide qu'un ticket relève du correctif ou de l'évolutif ? Sans définition écrite de l'anomalie et sans arbitrage prévu, chaque désaccord devient une négociation commerciale.
  3. Les niveaux de service. Distinguez le délai de prise en compte du délai de rétablissement, avec trois niveaux de gravité définis en termes métier : bloquant si le processus s'arrête, majeur s'il existe un contournement, mineur sinon. Précisez les heures couvertes et le canal de signalement.
  4. La veille sur les fins de support. Engagement de signaler les échéances des composants au moins six mois à l'avance, avec un inventaire des dépendances tenu à jour.
  5. Le volume d'évolutif. Une enveloppe annuelle en jours, reportable ou non, et un rythme de comité de priorisation. Sans enveloppe, l'évolutif ne se fait jamais.
  6. La documentation vivante. Procédures de mise en production et de restauration, schéma des flux, inventaire des accès, livrés à jour chaque trimestre et non à la seule fin du contrat.
  7. La propriété des comptes et des secrets. Dépôt de code, hébergement, comptes développeur mobile, clés d'API et noms de domaine au nom de votre entreprise, le prestataire étant utilisateur et non propriétaire.
  8. La réversibilité. Elle mérite sa propre section.

Code source et réversibilité : le vrai point de rupture

Un logiciel développé pour vous ne vous appartient pas automatiquement : les droits d'auteur restent au créateur tant qu'une cession écrite ne les transfère pas, et la remise du code source ne se présume pas. La jurisprudence a déjà donné raison à un client qui réclamait la communication du code pour confier la maintenance applicative à un tiers, notamment devant la cour d'appel de Douai le 7 avril 2022. Mieux vaut gagner ce point à la signature que devant un juge.

Une clause de réversibilité utile prévoit quatre choses : la restitution du code et des données dans un format réexploitable, un délai et un prix connus à l'avance pour l'assistance au repreneur, la durée de cette assistance et un test de la restitution. Un dépôt de code que personne n'a jamais réussi à compiler ailleurs n'est pas une réversibilité. Pour les cas sensibles, le dépôt chez un tiers de confiance, avec conditions de déblocage écrites, complète le dispositif.

Le même raisonnement vaut pour les données : le droit à la portabilité de l'article 20 du RGPD ne couvre que les données personnelles fournies par les personnes concernées, il ne vous rendra pas votre historique de production. Seul le contrat le fera.

Cadrer le budget sans se mentir

Deux modèles cohabitent. Le forfait couvre le correctif, l'adaptatif et le préventif pour un montant mensuel : il achète de la prévisibilité. L'enveloppe de jours convient à l'évolutif, dont le volume n'est pas prévisible. Fondre les deux dans une seule ligne de facture est la meilleure façon de ne jamais savoir ce que l'on paie.

Deux repères pour la discussion budgétaire. Le coût de la maintenance se compare au coût d'un arrêt du processus concerné, jamais au prix du développement initial : une application peu utilisée ne mérite pas le niveau de service d'un outil dont dépend la facturation. Ensuite, la reprise d'une application écrite par quelqu'un d'autre suppose une phase d'appropriation facturée et bornée avant tout engagement de délai : un prestataire qui s'engage sur des niveaux de service sans avoir lu le code ne s'engage sur rien.

Cinq erreurs fréquentes

  • Signer une maintenance sans vérifier que l'on possède le code. Le sujet se découvre toujours au moment de partir.
  • Confondre hébergement et maintenance applicative. L'hébergeur maintient la machine, pas votre code ni vos dépendances.
  • Accepter des niveaux de service exprimés en seul pourcentage de disponibilité. Une application disponible dont une fonction clé échoue silencieusement respecte le taux et bloque le métier.
  • Ne pas nommer de référent côté client. Sans interlocuteur capable de qualifier et de prioriser, le prestataire arbitre seul.
  • Laisser mourir la documentation. Elle est le seul actif qui rend la mise en concurrence possible à l'échéance.

Questions fréquentes

Quelle différence entre TMA et maintenance informatique ?

La maintenance informatique classique porte sur le matériel, le réseau et les postes de travail. La tierce maintenance applicative porte sur le code d'une application et ses intégrations. Les deux relèvent souvent d'acteurs différents et ne se remplacent pas.

Peut-on confier la maintenance à un autre prestataire que celui qui a développé l'application ?

Oui, à condition de disposer du code source, de la documentation et des accès. C'est l'objet des clauses de cession de droits et de réversibilité, à vérifier avant la fin du projet initial plutôt qu'après.

Combien coûte une tierce maintenance applicative ?

Le prix dépend du périmètre couvert, des heures de service, des délais de rétablissement engagés et de l'état technique de l'application. Un existant mal documenté coûte plus cher à maintenir, d'où l'intérêt d'un audit avant toute proposition chiffrée.

Que se passe-t-il si le langage de mon application n'est plus supporté ?

L'application continue de fonctionner, mais les failles découvertes ne sont plus corrigées officiellement et certains hébergeurs finissent par refuser la version. Il faut planifier la montée de version six à douze mois avant la date de fin de support.

Faut-il un contrat pour une application interne peu utilisée ?

Un contrat allégé reste utile, ne serait-ce que pour les mises à jour de sécurité et la garantie qu'une personne connaît encore l'application. A minima, faites documenter la procédure de restauration et conservez les accès en interne.

Avant de renégocier, ouvrez le contrat en cours et cherchez les mots réversibilité, code source et fin de support : leur absence est déjà un diagnostic. Pulsar Forge développe, reprend et maintient des applications métier sur mesure ; audit d'un contrat existant, reprise d'une application orpheline ou modernisation progressive, nous commençons par un état des lieux écrit et chiffré.

Parlons de votre projet