Contrat de TMA : sécuriser la tierce maintenance applicative

Un contrat de tierce maintenance applicative n'est pas un contrat d'infogérance. L'infogérance porte sur l'exploitation du système d'information, l'hébergement, la supervision, les sauvegardes. La TMA porte sur le code applicatif lui-même : corriger, adapter, faire évoluer. Confondre les deux produit toujours le même contrat, celui où le prestataire s'engage sur une disponibilité qu'il ne maîtrise pas et où le client paie deux fois les mêmes développements. Si votre sujet est l'exploitation de l'infrastructure, lisez plutôt notre guide sur la rédaction d'un contrat d'infogérance. Ce qui suit traite l'applicatif, et il le traite des deux côtés de la table : l'ESN qui veut une TMA rentable et bornée, le client qui veut un service réellement opposable.

TMA ou infogérance : deux contrats que tout oppose

Le vocabulaire n'est pas laissé au hasard des propositions commerciales. Le cahier des clauses administratives générales applicable aux marchés publics de techniques de l'information et de la communication, dans sa version approuvée en 2021, définit à son article 38 la tierce maintenance applicative comme les prestations « qui consistent à conserver un système d'information dans un état lui permettant de remplir sa fonction », exécutées à titre préventif ou correctif, et pouvant « également concerner des prestations d'évolution ou d'adaptation des logiciels ». Le même article définit l'infogérance comme « l'externalisation des prestations de gestion ou d'exploitation de tout ou partie du système informatique ».

Ce texte ne s'impose qu'aux marchés publics qui s'y réfèrent, mais il fournit le vocabulaire que les deux parties utiliseront devant un juge, et il pose la bonne frontière : la TMA vit dans le code, l'infogérance vit dans l'exploitation.

La conséquence est immédiate sur les engagements. Un contrat d'infogérance se mesure en taux de disponibilité, parce que le prestataire tient la plateforme. Un contrat de TMA se mesure en délais de prise en compte et de rétablissement par niveau de criticité, parce que le prestataire tient le correctif, pas le serveur. Une TMA recopiée d'un modèle d'infogérance promet un taux de disponibilité mensuel de 99,9 % à un prestataire qui ne contrôle ni l'hébergement, ni la fenêtre de déploiement, ni les tiers appelés par l'application. L'engagement est intenable dès la signature.

La qualification du contrat, et ce qu'elle emporte

Une TMA n'est ni une vente ni une location de matériel : c'est un louage d'ouvrage au sens de l'article 1710 du code civil, « un contrat par lequel l'une des parties s'engage à faire quelque chose pour l'autre, moyennant un prix convenu entre elles ». De cette qualification, la jurisprudence tire de longue date deux obligations que le contrat n'a pas besoin de stipuler pour qu'elles existent : un devoir de conseil du prestataire, qui doit alerter sur ce qu'il constate en maintenant l'application, et une obligation de collaboration du client, qui doit fournir les accès, les environnements et les informations permettant de reproduire une anomalie. Elles existent sans clause, mais elles se précisent utilement par écrit : liste des éléments dus par le client, délais de fourniture, effet de leur absence sur les niveaux de service.

Quand le même prestataire vend les deux, la règle est de séparer les lots : un périmètre applicatif avec ses propres niveaux de service, un périmètre d'exploitation avec les siens, et une clause qui traite les incidents situés à la frontière. Sans cette séparation, chaque coupure d'infrastructure devient une anomalie applicative.

Les quatre maintenances, et le glissement qui ruine une TMA

Le même article 38 distingue quatre régimes, et cette distinction est la colonne vertébrale du contrat. Le préventif désigne « les mesures d'entretien exécutées pour éviter la survenance d'anomalies ». Le correctif consiste à « corriger les anomalies ». L'évolutif vise à « faire évoluer une ou plusieurs applications, afin d'intégrer de nouvelles fonctions, d'en améliorer le fonctionnement et l'ergonomie ou de prendre en compte de nouvelles dispositions législatives ou règlementaires ». L'adaptatif permet « d'absorber des modifications de l'environnement technique d'exécution », mise à jour de système d'exploitation, changement de base de données, évolution d'une interface d'échange ou d'une bibliothèque.

Le point de bascule : qu'est-ce qu'une anomalie

Tout le contrat tient dans cette phrase : une anomalie est un écart entre le comportement observé et un référentiel documentaire annexé au contrat. Spécifications fonctionnelles, documentation livrée, procès-verbal de recette. Sans référentiel opposable, la définition de l'anomalie devient un rapport de force. Le client tranche que tout est correctif, donc compris dans le forfait. Le prestataire tranche que tout est évolutif, donc facturable au bordereau.

Le coût du flou se calcule. Prenons un forfait de quinze jours-homme par mois à 700 euros la journée, soit 10 500 euros mensuels. Si un quart de la capacité part chaque mois en évolutions requalifiées en corrections, le prestataire offre 31 500 euros par an, sur une marge qui ne les contient pas. Côté client, le symptôme inverse se chiffre aussi bien : trois devis d'évolution par trimestre pour des comportements que les spécifications décrivaient déjà, et un budget de TMA qui double en deux exercices.

Le dispositif contractuel qui tient repose sur quatre pièces : un référentiel documentaire annexé et versionné, un catalogue d'unités d'œuvre pour l'évolutif, une enveloppe d'évolutions incluse dans le forfait avec une règle de report explicite, et un comité mensuel compétent pour arbitrer les requalifications. Sur les autres pièges de rédaction propres aux prestations informatiques, notre article sur les pièges des contrats de prestation informatique complète utilement ce point.

Point de vigilance : quand une TMA reprend une application livrée par un autre prestataire, la première année ne sert pas à maintenir, elle sert à absorber les défauts de conception initiaux. Ces défauts ne sont ni du correctif ni de l'évolutif au sens du contrat. Prévoyez une phase de reprise avec un audit d'entrée, un état des lieux contradictoire et une liste des anomalies préexistantes exclues du forfait. Sans cela, le prestataire entrant hérite gratuitement des erreurs du sortant.

GTI, GTR et grille de criticité : le vrai champ de bataille

Les niveaux de service d'une TMA reposent sur deux engagements. La garantie de temps d'intervention est le délai de prise en charge d'un ticket, à compter de son horodatage. La garantie de temps de rétablissement est le délai pour remettre le service en état, contournement accepté ou correction définitive selon ce que le contrat prévoit. Confondre les deux fait perdre le procès à celui qui n'a pas lu.

Une grille qui tient devant un juge

Une grille exploitable qualifie par impact métier et par existence d'un contournement, jamais par ressenti. Criticité 1 : service indisponible ou fonction critique inutilisable sans contournement, prise en charge en deux heures ouvrées, rétablissement visé en quatre heures. Criticité 2 : fonction dégradée avec contournement, quatre heures et un jour ouvré. Criticité 3 : gênant mais contournable, un jour et cinq jours ouvrés. Criticité 4 : cosmétique, traité à la prochaine livraison planifiée.

Trois mécanismes rendent cette grille opposable. Le premier est la source de l'horodatage : l'outil de gestion des tickets fait foi, pas un courriel envoyé à un chef de projet en congés. Le deuxième est la suspension du décompte pendant l'attente d'un élément dû par le client, jeu de données, accès à un environnement, validation d'un correctif en recette, avec reprise à la fourniture. Le troisième est la procédure de qualification : le prestataire propose un niveau, le client peut le contester dans un délai court, et l'arbitrage remonte au comité de pilotage. Sans cette procédure, un client classe tout en criticité 1 et un prestataire déclasse tout en criticité 3.

Reste la question de la nature de l'engagement. Le délai de prise en charge ne dépend que de l'organisation du prestataire : il se stipule en obligation de résultat. Le délai de rétablissement dépend d'éléments extérieurs, accès aux environnements, disponibilité d'un tiers, hébergeur, éditeur d'un composant. Il se stipule en engagement renforcé assorti d'une clause de dépendance qui liste précisément les cas de suspension. Promettre un rétablissement ferme sur un applicatif hébergé et déployé par un tiers, c'est signer une obligation dont on ne détient pas les moyens.

Pénalités, plafonds et responsabilité : ce que le juge peut réécrire

Les pénalités de service sont des clauses pénales. L'article 1231-5 du code civil prévoit que le juge « peut, même d'office, modérer ou augmenter la pénalité ainsi convenue si elle est manifestement excessive ou dérisoire », et que « toute stipulation contraire aux deux alinéas précédents est réputée non écrite ». Autrement dit, aucune rédaction ne met une pénalité à l'abri d'une révision judiciaire, ni dans un sens ni dans l'autre. Le même texte ajoute que, sauf inexécution définitive, la pénalité n'est encourue qu'après mise en demeure. En pratique, cela condamne les contrats où les pénalités sont censées se déclencher toutes seules : prévoyez un relevé mensuel de niveaux de service valant constat, et une notification écrite dans un délai bref.

Trois précisions manquent dans la plupart des contrats de TMA que je relis. La pénalité est-elle libératoire, c'est-à-dire exclut-elle toute autre indemnisation pour le même manquement ? Existe-t-il un plafond mensuel de pénalités, exprimé en pourcentage de la redevance du mois concerné, un plafond de 10 à 15 % étant défendable des deux côtés ? Le franchissement répété d'un seuil ouvre-t-il un droit de résiliation pour faute, sans indemnité ? C'est la seule sanction qui pèse réellement.

Le plafond de responsabilité et sa limite

Le plafond global de responsabilité est le point où les intérêts divergent le plus. Le prestataire veut un plafond bas, le client veut une couverture réelle. La limite est posée par l'article 1170 du code civil : « toute clause qui prive de sa substance l'obligation essentielle du débiteur est réputée non écrite ». Un plafond fixé à un mois de redevance sur un contrat qui maintient l'application de facturation d'un groupe, combiné à une exclusion de tous les préjudices immatériels, est le cas d'école de la clause attaquable. Le client obtient alors, dans le pire des cas pour le prestataire, une indemnisation sans plafond.

La rédaction équilibrée existe : plafond exprimé en montant des redevances effectivement payées sur les douze mois précédant le fait générateur, exclusions définies limitativement et non par une formule attrape-tout, réserve expresse pour la faute lourde ou dolosive, les dommages corporels, les manquements à la confidentialité et les violations de données personnelles, attestation annuelle d'assurance de responsabilité civile professionnelle avec un montant de garantie cohérent avec le plafond. Quand un projet dérape au point de finir en contentieux, les leviers disponibles sont ceux que nous détaillons dans notre article sur les recours en cas d'échec de projet informatique.

À qui appartiennent les évolutions livrées en TMA

C'est la clause la plus souvent bâclée, et celle qui coûte le plus cher à la sortie. L'article L113-9 du code de la propriété intellectuelle dévolut à l'employeur, sauf stipulation contraire, les droits patrimoniaux sur les logiciels créés par ses salariés dans l'exercice de leurs fonctions. Dans une TMA, cet employeur est l'ESN. Le client qui paie les évolutions n'acquiert aucun droit du seul fait du paiement.

Pour que le client détienne quelque chose, il faut une cession écrite conforme à l'article L131-3 du même code : chacun des droits cédés doit faire l'objet d'une mention distincte, et le domaine d'exploitation doit être délimité « quant à son étendue et à sa destination, quant au lieu et quant à la durée ». La clause « le client est propriétaire de l'ensemble des développements réalisés » ne remplit aucune de ces conditions. Elle survit tant que personne ne la conteste, et elle tombe le jour où elle sert à quelque chose : une revente, une levée de fonds, un audit d'acquéreur.

Une cession de droits futurs se rédige avec un mécanisme d'identification des œuvres, en général par référence aux bons de commande et aux procès-verbaux de recette, et un déclencheur de transfert. Le déclencheur le plus fréquent est le paiement intégral de la prestation concernée. Il faut alors écrire ce qui se passe en cas de paiement partiel, et coupler le transfert à la remise des sources. Le contentieux ayant conduit à l'arrêt de la chambre commerciale de la Cour de cassation du 15 décembre 2009 (pourvoi n° 08-19.800) illustre ce risque : le contrat de distribution et de tierce maintenance applicative en cause subordonnait le transfert des droits sur chaque module au règlement définitif et intégral du prix, et l'affaire a tourné pendant des années autour de la remise des fichiers sources et exécutables du logiciel.

Côté prestataire, la symétrie est vitale. Une ESN qui cède l'intégralité de ce qu'elle produit cède son fonds de commerce ligne à ligne. La rédaction protectrice exclut de la cession les briques génériques, outils internes, frameworks et composants préexistants, et les concède au client sous licence non exclusive, perpétuelle et transférable pour les besoins de l'application. Côté client, la contrepartie est tout aussi concrète : une cession de code sans documentation d'architecture, sans scripts de construction et sans description de la chaîne de déploiement cède un objet inexploitable.

Accès au code source, droit de corriger et séquestre

Avant de confier la maintenance d'un logiciel à un tiers, il faut vérifier qu'on en a le droit. L'article L122-6-1 du code de la propriété intellectuelle autorise la personne ayant le droit d'utiliser le logiciel à accomplir les actes nécessaires à son utilisation conforme à sa destination, « y compris pour corriger des erreurs ». Mais le même texte ajoute que « l'auteur est habilité à se réserver par contrat le droit de corriger les erreurs ». Cette réserve figure dans la majorité des licences d'éditeurs. Quand elle est présente, confier la correction du progiciel à une ESN tierce n'est pas une décision d'organisation, c'est un acte de contrefaçon potentielle.

La Cour de justice de l'Union européenne a précisé la marge restante dans son arrêt Top System du 6 octobre 2021 (affaire C-13/20) : l'acquéreur légitime d'un programme peut le décompiler, en tout ou partie, pour corriger des erreurs affectant son fonctionnement, y compris lorsque la correction consiste à désactiver une fonction défectueuse, sous réserve des conditions posées par la directive. C'est une soupape juridique, pas un mode opératoire industriel : personne ne fonde un plan de maintenance sur la décompilation.

D'où le séquestre. Un dépôt du code chez un tiers de confiance, avec quatre exigences que je vérifie systématiquement : la complétude du dépôt, qui comprend les sources, la documentation d'installation, la liste des dépendances et les scripts de construction ; la fréquence de mise à jour, alignée sur le rythme des livraisons et non sur une périodicité annuelle décorative ; les conditions de libération, procédure collective du prestataire, cessation de la maintenance, manquement grave répété constaté ; et un test de restitution effectué au moins une fois par an. Un séquestre jamais testé n'est pas un plan de secours, c'est une ligne de facture.

Conseil d'avocat : dans un audit de contrat de TMA, je commence toujours par deux documents, la licence du logiciel maintenu et le dernier bordereau de dépôt du séquestre. Si la licence réserve la correction à l'éditeur et si le séquestre date de dix-huit mois, aucune clause de niveau de service ne vaut quoi que ce soit. Le contrat promet un service que le droit interdit et que la technique ne permet pas de reprendre.

Données personnelles et sécurité : les deux annexes qu'on oublie

Le volet RGPD de la TMA

Dès que le prestataire accède aux données de production, il traite des données personnelles pour le compte de son client, et il devient sous-traitant au sens de l'article 28 du règlement général sur la protection des données. Cet accès se produit dans presque toutes les TMA : reproduire une anomalie sur un jeu de données réel est la méthode la plus rapide, donc la plus employée.

Le contrat de sous-traitance doit alors exister, avec les mentions imposées par le texte : traitement sur instruction documentée, engagement de confidentialité des personnes autorisées, mesures de sécurité, autorisation de recourir à des sous-traitants ultérieurs, assistance du responsable de traitement, sort des données en fin de contrat. Cette annexe se négocie dans les deux sens, et l'éditeur qui la reçoit d'un grand compte a intérêt à savoir ce qu'il signe : c'est l'objet de notre mode d'emploi du DPA pour un éditeur SaaS.

Trois points méritent une clause explicite. La localisation des équipes : une équipe de maintenance hors Union européenne qui se connecte à la base de production réalise un transfert, avec la documentation que cela impose. Les jeux de données : anonymisation ou pseudonymisation des extractions destinées aux environnements de test, interdiction de copier une base de production sur un poste de travail. Les accès : comptes nominatifs, accès administré et journalisé, durée d'habilitation limitée, revue trimestrielle des droits.

Maintien en condition de sécurité : ce que le règlement européen change

Le maintien en condition opérationnelle et le maintien en condition de sécurité sont deux prestations distinctes, et la seconde est presque toujours sous-écrite. Elle recouvre des obligations concrètes : appliquer les correctifs de sécurité des composants tiers, dans un délai fonction de la criticité de la vulnérabilité, suivre les fins de support des bibliothèques et des versions de langage, et signaler au client toute vulnérabilité connue affectant l'application. Sans ces lignes, personne ne met à jour une dépendance obsolète parce que personne n'a accepté d'en payer la régression.

Le contexte réglementaire durcit l'enjeu. Le règlement européen sur la cyberrésilience, le règlement (UE) 2024/2847, impose aux fabricants de produits comportant des éléments numériques, catégorie qui inclut les logiciels, de signaler les vulnérabilités activement exploitées et les incidents graves. Selon la documentation publiée par la Commission européenne et par la direction générale des entreprises, ces obligations de signalement s'appliquent depuis le 11 septembre 2026, avec une alerte précoce dans les vingt-quatre heures et une notification dans les soixante-douze heures, le reste des obligations devenant applicable le 11 décembre 2027, dont une période de support d'au moins cinq ans pendant laquelle les mises à jour de sécurité sont fournies gratuitement.

La traduction contractuelle est immédiate : un éditeur qui a confié sa maintenance à une ESN ne peut pas alerter en vingt-quatre heures si son contrat prévoit une prise en charge en cinq jours ouvrés. Il faut une clause de remontée immédiate des vulnérabilités, un canal dédié distinct du support standard, une obligation de coopération à la notification et une répartition des coûts des correctifs de sécurité hors forfait. Côté ESN, la contrepartie est de borner l'engagement aux composants listés en annexe, faute de quoi la clause devient une veille illimitée.

La réversibilité, la clause qu'on écrit le premier jour et qu'on lit le dernier

Une TMA finit toujours. Par un appel d'offres perdu, par un rachat, par une rupture. La réversibilité est ce qui sépare une transition de trois mois d'un contentieux de trois ans, et elle ne se négocie jamais au moment où on en a besoin : à ce moment-là, le rapport de force a changé de camp.

Un plan de réversibilité s'annexe au contrat le jour de la signature et s'actualise chaque année. Il liste les livrables : code source à jour et documentation d'architecture, procédures d'exploitation et de déploiement, jeux de tests, historique des tickets, inventaire des accès et des comptes de service, liste des dépendances et de leurs licences. Il fixe une durée réaliste, trois à six mois selon la complexité, une charge et un prix, en jours plafonnés au tarif du contrat plutôt qu'en devis à établir le moment venu. Il prévoit le gel des évolutions pendant la période, une phase de transfert de connaissance avec le repreneur, et une assistance résiduelle de trente à soixante jours après la bascule. Le cahier des clauses administratives générales déjà cité impose d'ailleurs, à son article 42, que le titulaire sortant fournisse un accès aux matériels et aux logiciels et mette en œuvre des mesures de sécurité lors du transfert des prestations.

Sortir du contrat sans commettre de faute

La durée et la reconduction méritent la même attention. Une TMA reconduite tacitement pendant six ans crée une relation commerciale établie, et l'article L442-1 du code de commerce engage la responsabilité de celui qui rompt brutalement, même partiellement, une telle relation « en l'absence d'un préavis écrit qui tienne compte notamment de la durée de la relation commerciale ». Le même texte sécurise l'auteur de la rupture qui accorde dix-huit mois de préavis, et réserve la résiliation sans préavis en cas d'inexécution ou de force majeure. Traduction : la clause de préavis de trente jours figurant au contrat ne protège pas le client qui coupe une TMA vieille de six ans, ni l'ESN qui décide d'arrêter du jour au lendemain une prestation devenue peu rentable.

Dernier réflexe, côté prestataire : la tentation de retenir le code ou les accès en cas d'impayés. La rétention improvisée se retourne presque toujours contre celui qui la pratique, en référé, dans des délais très courts. Mieux vaut une clause de suspension encadrée, avec seuil d'impayés, mise en demeure préalable, délai et périmètre de la suspension écrits à l'avance.

Ce qu'il faut obtenir, de chaque côté de la table

Côté client, cinq exigences non négociables :

• un référentiel documentaire annexé qui définit ce qu'est une anomalie ;
• une grille de criticité avec procédure de qualification et d'arbitrage ;
• une cession de droits conforme à l'article L131-3, couplée à la remise des sources et de la documentation de construction ;
• un séquestre à jour, testé une fois par an ;
• un plan de réversibilité chiffré, annexé dès la signature.

Côté prestataire, cinq protections symétriques :

• une frontière écrite entre correctif, adaptatif et évolutif, avec catalogue d'unités d'œuvre ;
• des niveaux de service assortis de causes de suspension explicites, dont l'attente d'un élément du client ;
• un plafond de pénalités mensuel et un plafond global de responsabilité aligné sur les redevances annuelles ;
• l'exclusion des briques génériques de la cession, remplacée par une licence d'utilisation ;
• une réversibilité rémunérée, bornée en charge et en durée.

Ces points se négocient mieux en amont, dans le cadre plus large d'un contrat informatique construit sur mesure, et ils constituent l'essentiel de ce que je révise pour les ESN, agences et prestataires IT comme pour leurs clients.

Un contrat de TMA solide ne fait pas gagner un litige : il évite d'en avoir un. La définition de l'anomalie, la grille de criticité, la propriété des évolutions et le plan de réversibilité représentent quatre annexes et deux jours de travail. Le contentieux qu'elles évitent se compte en dizaines de milliers d'euros et en mois d'immobilisation d'une application dont personne ne détient plus les sources.

Si vous relisez une TMA, la vôtre ou celle qu'on vous propose, passez-la au simulateur de cette page pour repérer les points faibles, puis échangeons sur votre situation : je relis le contrat, je liste ce qui est réellement opposable, et je vous dis ce qu'il faut obtenir avant de signer.