Contrat de TMA : 5 clauses essentielles avec exemples

La tierce maintenance applicative (ou « TMA ») est l’un des contrats informatiques les plus répandus dans les entreprises et pourtant l’un des moins bien rédigés.

L’explication tient souvent à une illusion de simplicité : puisqu’il s’agit « seulement » de maintenir un logiciel en état de marche, on croit pouvoir se contenter d’un contrat allégé, d’un bon de commande récurrent ou d’un échange d’e-mails. C’est une erreur qui se paie cher.

La TMA engage le prestataire sur des obligations d’une grande technicité (tels que corriger les anomalies, faire évoluer le système, assurer la continuité des applications critiques) dont l’inexécution peut paralyser tout ou partie de l’activité du client.

Voici les cinq clauses, accompagnées d’exemples, autour desquelles se joue l’essentiel.

1. La clause d’objet et de périmètre : délimiter précisément ce qui est maintenu

C’est la clause dont dépend la cohérence de tout le reste. Un contrat de TMA sans périmètre précis est un contrat sans fond : le prestataire peut y voir une mission limitée à la correction des bugs critiques, quand le client en attend une prise en charge globale incluant les évolutions réglementaires, les montées de version et l’assistance aux utilisateurs. Ce malentendu originel nourrit la grande majorité des litiges en matière de maintenance informatique.

La pratique distingue plusieurs catégories de maintenance qu’il convient d’articuler avec soin :

• La maintenance corrective couvre la détection et la résolution des anomalies et dysfonctionnements qui empêchent le système d’atteindre ses niveaux de performance convenus.
• La maintenance préventive désigne les opérations planifiées destinées à anticiper les défaillances, améliorer la stabilité du système et réduire sa dette technique.
• La maintenance évolutive englobe les modifications fonctionnelles ou techniques rendues nécessaires par l’évolution du contexte : changements légaux et réglementaires, mises à jour de l’éditeur du logiciel sous-jacent, évolutions de l’environnement technique.

Chacune de ces catégories a une économie propre et doit faire l’objet d’une description distincte dans le contrat.

La clause doit également préciser l’environnement technique couvert : versions de l’application maintenue, système d’exploitation, base de données, middleware, navigateurs, interfaces et flux avec les applications tierces. Faute de cette précision, le prestataire pourra légitimement soutenir que la défaillance d’une interface avec un système tiers ne relève pas de son périmètre ce qui est juridiquement défendable mais opérationnellement désastreux pour le client.

Enfin, la liste des exclusions mérite autant de soin que la liste des inclusions. Formations des utilisateurs, assistance métier, développements entièrement nouveaux, support de l’éditeur du progiciel : tout ce qui n’est pas expressément inclus doit être explicitement exclu pour éviter les glissements de périmètre et les demandes de prestation gratuite que le client formulera inévitablement.

Exemple de clause : « Le présent contrat a pour objet la prise en charge par le Prestataire de la tierce maintenance applicative des applications listées à l’Annexe 1, dans leurs versions en production à la date d’entrée en vigueur du contrat et les versions ultérieures livrées en cours d’exécution. La TMA comprend : (i) la maintenance corrective, entendue comme le traitement des anomalies bloquantes, majeures et mineures selon la classification définie à l’Annexe 2 ; (ii) la maintenance préventive et perfective, constituée des opérations planifiées de stabilisation, de mise à jour de sécurité et d’amélioration de la performance ; (iii) la maintenance évolutive, limitée aux évolutions rendues nécessaires par des modifications légales ou réglementaires ou par des changements de version de l’éditeur imposés dans le périmètre défini à l’Annexe 1. Sont expressément exclus du périmètre : les développements fonctionnels nouveaux dont la charge dépasse [X] jours-hommes, les formations des utilisateurs finaux, l’assistance à la conduite du changement, ainsi que toute intervention sur des composants tiers non listés à l’Annexe 1. »

Point de vigilance pour le client : veillez à ce que l’Annexe 1 décrivant le périmètre applicatif soit maintenue à jour pendant toute la durée du contrat. Un système entré en production après la signature du contrat initial, et intégré sans avenant, crée immédiatement une zone grise sur les obligations du prestataire à son égard.

2. La convention de niveaux de service (SLA) : transformer les obligations vagues en engagements mesurables

Sans SLA, le contrat de TMA reste à l’état de promesse. La convention de niveaux de service est l’instrument qui traduit les obligations du prestataire en engagements chiffrés, vérifiables et sanctionnables. C’est aussi le document qui détermine, en cas de litige, si le prestataire a ou non rempli ses obligations et, par conséquent, si les pénalités s’appliquent ou si la résiliation pour faute est justifiée.

Le SLA doit couvrir au minimum 4 indicateurs opérationnels :

• Le délai de prise en compte mesure le temps entre la déclaration d’un incident par le client et son accusé de réception formel par le prestataire : il est préférable pour le client de le différencier selon le niveau de criticité de l’anomalie
• Le délai de diagnostic fixe le temps dans lequel le prestataire doit avoir identifié la cause racine de l’incident et communiqué une analyse au client.
• Le délai de résolution ou, à défaut, de mise en place d’une solution de contournement opérationnelle est l’engagement central du contrat de TMA : c’est lui qui détermine combien de temps les utilisateurs resteront bloqués en cas d’anomalie bloquante.
• Le taux de disponibilité des applications, enfin, est pertinent lorsque la TMA inclut une composante d’hébergement ou d’infogérance.

La définition des modalités de mesure est aussi importante que les chiffres eux-mêmes. Un taux de disponibilité de 99,5 % calculé sur des horaires de bureau étendue (7h-21h, du lundi au vendredi) représente une réalité opérationnelle très différente d’un taux identique mesuré 24h/24, 7 jours sur 7. Ces précisions doivent figurer dans le contrat, faute de quoi le prestataire interprétera logiquement toute ambiguïté en sa faveur.

Exemple de clause : « Les niveaux de service garantis par le Prestataire sont définis à l’Annexe 2 selon la grille de criticité suivante : anomalie de niveau 1 (bloquante et urgente) : prise en compte sous 1 heure, solution de contournement sous 4 heures ouvrées, résolution définitive sous 2 jours ouvrés ; anomalie de niveau 2 (bloquante non urgente) : prise en compte sous 4 heures ouvrées, résolution sous 5 jours ouvrés ; anomalie de niveau 3 (non bloquante) : prise en compte sous 1 jour ouvré, résolution sous 15 jours ouvrés. Ces délais courent à compter de la déclaration formelle de l’anomalie par le Client dans l’outil de ticketing désigné à l’Annexe 4. Le Prestataire produit un rapport mensuel de suivi des niveaux de service, adressé au référent Client désigné dans les 5 jours suivant la clôture du mois. Tout dépassement des délais contractuels expose le Prestataire aux pénalités définies à l’article [X], sauf à démontrer que le dépassement est imputable au Client ou à un cas de force majeure. »

Point de vigilance pour le client : les pénalités de SLA ne sont utiles que si elles sont réellement dissuasives. Un plafond de pénalités fixé à 5 % de la redevance mensuelle pour une anomalie bloquante non résolue pendant 48 heures n’incitera pas le prestataire à mobiliser les ressources nécessaires. Calibrez les pénalités en proportion du préjudice effectif que représente l’indisponibilité de l’application concernée pour votre activité.

3. La clause d’obligations du prestataire : formaliser l’exigence d’efficacité

Le régime juridique de la maintenance informatique repose sur ce que la jurisprudence qualifie d’obligation d’efficacité : le prestataire n’est pas seulement tenu de déployer des diligences, il doit obtenir un résultat opérationnel.

Cette obligation, dont le contenu a été progressivement précisé par les décisions de justice, implique que le mainteneur intervienne selon les règles de l’art, respecte les préconisations de l’éditeur du logiciel concerné, procède à un diagnostic documenté pour chaque incident significatif, et ne considère son intervention comme terminée qu’après avoir effectué les tests confirmant que l’anomalie est effectivement résolue.

Cette obligation d’efficacité a plusieurs corollaires pratiques que la rédaction du contrat doit intégrer.

• Le prestataire doit maintenir ses propres compétences à jour notamment pour les progiciels dont les versions évoluent rapidement et assurer la continuité de service en cas de changement de ses intervenants.
•  Il doit également gérer l’obsolescence des composants : lorsqu’un module ou une bibliothèque utilisée dans le système maintenu atteint sa fin de vie, le prestataire ne peut se contenter de constater l’impossibilité d’intervenir ; il doit proposer une alternative permettant au client de maintenir le bon fonctionnement de ses applications.

Le contrat doit par ailleurs organiser les obligations documentaires du prestataire. Chaque intervention significative doit donner lieu à un compte rendu technique précisant la cause de l’anomalie, les actions réalisées, les tests effectués et les préconisations éventuelles pour éviter la récurrence. Cette documentation constitue à la fois un outil de pilotage pour le client et une pièce essentielle en cas de litige sur la qualité des prestations.

Exemple de clause : « Le Prestataire s’engage à réaliser les interventions de maintenance conformément aux règles de l’art et aux préconisations en vigueur de l’éditeur des applications couvertes. Pour toute anomalie de niveau 1 ou 2, il produit un compte rendu d’intervention documentant la cause racine identifiée, les actions correctives mises en œuvre, les tests de non-régression effectués et, le cas échéant, les mesures préventives recommandées. Ce compte rendu est transmis au Client dans les 2 jours ouvrés suivant la résolution de l’anomalie. Le Prestataire garantit la continuité des compétences affectées à l’exécution du contrat et s’engage à assurer le transfert de connaissance interne en cas de changement d’intervenant, sans que ce changement ne dégrade les niveaux de service contractuels. En cas d’obsolescence d’un composant du périmètre maintenu, le Prestataire en informe le Client sans délai et lui soumet, dans un délai de [X] jours, une proposition de migration ou de substitution permettant le maintien en condition opérationnelle. »

Point de vigilance pour le client : ne pas confondre obligation d’efficacité et obligation de résultat absolue. Certaines anomalies non reproductibles sur des environnements de test ne peuvent pas être corrigées avec certitude : le contrat doit distinguer ce cas et prévoir une procédure spécifique (par ex., surveillance renforcée, escalade vers l’éditeur) sans que le non-respect des délais dans cette hypothèse entraîne automatiquement des pénalités.

4. La clause de réversibilité : éviter les conflits à la fin du contrat de TMA

La réversibilité est la clause que les clients négligent le plus systématiquement à la signature et qu’ils regrettent le plus amèrement en fin de contrat.

Dans une relation de TMA, le prestataire accumule au fil du temps une connaissance fonctionnelle et technique du système du client qui, si elle n’est pas documentée et transférable, constitue une forme de dépendance dont ce dernier aura toutes les peines du monde à s’affranchir.

La réversibilité ne se résume pas à une obligation de restituer les codes sources : elle suppose un transfert effectif de la capacité à maintenir les applications, que ce soit en interne ou par un prestataire entrant.

Cela implique plusieurs composantes distinctes :

• la remise de l’ensemble de la documentation technique et fonctionnelle tenue à jour, la restitution des scripts, des paramètrages et des dossiers d’exploitation
• l’organisation d’une période de compagnonnage pendant laquelle le prestataire sortant accompagne le client ou le prestataire entrant
• et la restitution ou la destruction certifiée de l’ensemble des données du client.

Le moment de la réversibilité est également critique. Elle ne peut pas s’improviser à l’expiration d’un préavis de 30 jours : pour un système applicatif complexe, une réversibilité sérieuse nécessite trois à six mois de préparation. Le contrat doit donc déclencher les obligations de réversibilité dès la notification de résiliation ou de non-renouvellement, indépendamment des motifs, et organiser un plan de transition formalisé avec des jalons précis.

La réversibilité s’articule étroitement avec les obligations issues du RGPD : en fin de contrat, le prestataire qui a accédé à des données personnelles dans le cadre de sa mission doit restituer ces données dans un format réutilisable ou en certifier la destruction. Ce point doit être réglé dans la clause de réversibilité elle-même et non renvoyé à une mention vague dans la politique de confidentialité.

Exemple de clause : « Dès la notification de résiliation ou de non-renouvellement du contrat, quelle qu’en soit la cause, le Prestataire est tenu de mettre en œuvre le Plan de réversibilité joint en Annexe [X]. Ce plan comprend : (i) la remise au Client, dans un délai de [15] jours à compter de la notification, de l’intégralité de la documentation applicative et technique tenue à jour, incluant les dossiers de paramétrage, les scripts d’exploitation, les cahiers de tests et les procédures d’exploitation ; (ii) une phase d’assistance au repreneur d’une durée minimale de [3 mois], pendant laquelle les équipes du Prestataire répondent aux questions du Client ou du prestataire entrant et participent aux comités de transition selon le calendrier défini ; (iii) la restitution des données du Client dans un format réutilisable ou, à défaut, leur destruction certifiée avec remise d’un certificat de destruction dans les [30] jours suivant la fin effective du contrat. Les prestations d’assistance au repreneur non incluses dans le forfait contractuel sont facturées au tarif figurant à l’Annexe 3. Le Prestataire ne peut en aucun cas conditionner l’exécution de ses obligations de réversibilité au règlement de sommes contestées par le Client. »

Point de vigilance pour le client : prévoyez explicitement que les obligations de réversibilité s’appliquent y compris en cas de résiliation pour faute du client : c’est souvent la situation la plus conflictuelle et un prestataire dont le contrat est résilié à ses torts ou dont une partie des prestations n’aura pas été payée aura peu d’incitation naturelle à coopérer à une transition facilitée.

5. La clause de propriété intellectuelle sur les correctifs et les évolutions : savoir à qui appartient les droits sur les prestations de TMA

C’est la clause que les parties oublient le plus souvent de négocier explicitement dans un contrat de TMA, en supposant implicitement que « ce qui est fait pour le client lui appartient ». Or, en droit français, cette présomption n’existe pas : c’est la personne physique qui réalise l’acte de création qui est l’auteur de l’œuvre, et les droits patrimoniaux ne se transmettent que par contrat écrit et dans les limites expressément définies par ce contrat, conformément à l’article L. 131-3 du code de la propriété intellectuelle.

Dans un contrat de TMA, la question se pose pour plusieurs catégories de livrables.

• Les correctifs apportés au code existant sont des modifications de l’œuvre initiale : leur régime dépend en partie de celui de l’œuvre originaire, mais les développements additionnels créés par le prestataire sont en principe sa propriété intellectuelle si le contrat ne prévoit rien.
• Les évolutions fonctionnelles constituent quant à elles de véritables développements nouveaux, qui peuvent atteindre un niveau d’originalité suffisant pour être protégés par le droit d’auteur.
• La documentation produite (par ex., notes techniques, procédures d’exploitation, guides de maintenance) est également une œuvre de l’esprit dont la titularité doit être clarifiée.

La clause doit distinguer la propriété intellectuelle préexistante du prestataire (tels que ses outils, frameworks, méthodes génériques) qu’il est légitime de protéger, et les développements spécifiques réalisés pour le client dans le cadre du contrat, sur lesquels ce dernier a vocation à obtenir des droits.

Cette distinction doit être opérée avec précision, car une formule trop large attribuant au client tous les droits sur « tout ce qui est produit dans le cadre du contrat » pourrait priver le prestataire de ses outils propriétaires, ce qui est inéquitable et généralement contre-productif.

Enfin, la clause doit prévoir la garantie d’éviction : le prestataire certifie qu’il est bien titulaire des droits qu’il cède et que les livrables ne portent atteinte à aucun droit de tiers ou de ses salariés ou sous-traitants. La question se pose également en matière de composants open source dont la licence peut imposer des conditions de distribution qu’il convient de respecter scrupuleusement.

Exemple de clause : « Le Prestataire conserve la propriété intellectuelle de ses outils, méthodes, frameworks et composants génériques préexistants au présent contrat, dont la liste est jointe en Annexe [X]. Pour l’utilisation de ces éléments dans le cadre de l’exécution du contrat, il accorde au Client une licence d’utilisation non exclusive, non transmissible, limitée aux seules fins d’exploitation des applications maintenues. Les correctifs, évolutions, interfaces, scripts et documentations développés spécifiquement pour le Client dans le cadre du présent contrat ( ci-après les « Livrables spécifiques ») font l’objet d’une cession au Client, au fur et à mesure de leur production et sous réserve du paiement des sommes correspondantes, de l’ensemble des droits patrimoniaux d’auteur, incluant les droits de reproduction, d’adaptation, de modification, d’utilisation et d’exploitation, pour le monde entier et pour toute la durée légale de protection. Le Prestataire garantit au Client la jouissance paisible des droits ainsi cédés et s’engage à l’indemniser de toute éviction due à ses propres manquements. Il remet au Client, simultanément à chaque livraison, les codes sources commentés et la documentation nécessaire à l’exploitation et à la maintenance ultérieure des Livrables spécifiques. »

Point de vigilance pour le client : assurez-vous que la clause couvre bien les composants open source intégrés par le prestataire dans ses livrables. Certaines licences copyleft (GNU GPL notamment) imposent que tout logiciel distribuant du code sous cette licence soit lui-même distribué sous les mêmes conditions, ce qui peut créer des contraintes significatives sur l’exploitation commerciale de vos applications si elles n’ont pas été anticipées contractuellement.

Le contrat de TMA est un engagement de long terme, souvent pluriannuel, dont les conséquences en cas de défaillance sont immédiatement opérationnelles. Les cinq clauses présentées ici (périmètre, SLA, obligations du mainteneur, réversibilité et propriété intellectuelle) constituent l’ossature d’un dispositif contractuel sérieux, mais elles supposent d’être complétées par des dispositions adaptées à chaque situation : clause RGPD intégrées dans un accord de sous-traitance (ou « DPA ») conforme à l’article 28 du règlement si le prestataire accède à des données personnelles, clause de gouvernance et de comité de pilotage pour les contrats de longue durée, clause de renégociation si l’équilibre économique du contrat doit pouvoir être réévalué périodiquement.

Les exemples de clauses proposés dans cet article ont une vocation pédagogique et ne constituent pas un conseil juridique. Ils doivent être adaptés aux caractéristiques spécifiques de chaque relation contractuelle avant toute utilisation. Si vous avez besoin d’assistance pour relire votre proposition de contrat de TMA, le modifier ou le rédiger intégralement, vous pouvez m’adresser votre demande ou réserver un entretien en cliquant ici.