Modèle de contrat de tierce maintenance applicative (TMA) gratuit (Word)

Sommaire

1. Quand utiliser ce contrat, et quand il ne convient pas
2. Ce que dit le droit français
3. Ce que contient ce modèle, article par article
4. Les pièges à éviter
5. Comment adapter ce modèle à votre situation
6. Ce que ce modèle ne remplace pas

Quand utiliser ce contrat, et quand il ne convient pas

Vous externalisez la maintenance d’une application en production. Une entreprise dont un logiciel métier est déjà déployé confie à un tiers sa maintenance corrective, préventive, adaptative et parfois évolutive. Le contrat de TMA fixe le périmètre applicatif couvert, les niveaux de service attendus et le sort des développements réalisés. Il organise une prestation récurrente, non une livraison ponctuelle de logiciel.

Vous êtes le prestataire de maintenance. Une ESN ou un développeur indépendant qui reprend le maintien d’une application dont il n’est pas l’auteur signe le même contrat, en position de prestataire. La vigilance porte alors sur le périmètre exact repris, sur l’accès à l’environnement et au code, et sur la répartition des obligations de moyens, pour ne pas être tenu de garantir un logiciel dont l’état initial n’a pas été audité.

L’application traite des données personnelles. Dès que le prestataire accède, dans le cadre de ses interventions, à des données de clients, de salariés ou de partenaires, il agit comme sous-traitant au sens de l’article 28 du RGPD. Le contrat doit alors être adossé à un acte de sous-traitance encadrant les accès, les mesures de sécurité et le sort des données consultées.

Vous distinguez la maintenance de la construction. La TMA suppose une application existante à entretenir. Si le besoin porte sur la création d’un logiciel neuf ou d’un module important, la gestion des évolutions au sein de la TMA ne suffit pas, et un contrat de réalisation est plus adapté.

Quand ce modèle ne convient pas. Si la prestation consiste à développer un logiciel nouveau livré au client, un contrat de développement au forfait est plus adapté que la TMA. Si le prestataire met à disposition des intervenants pilotés directement par le client, sans engagement de résultat sur un périmètre applicatif, la relation relève de la régie informatique et appelle une vigilance particulière sur le prêt de main-d’œuvre. Si l’application est fournie en ligne par son éditeur, la maintenance est généralement incluse dans le contrat SaaS et non externalisée à un tiers. [À VÉRIFIER JURISTE : frontière entre TMA au forfait et régie selon le montage retenu.]

Ce que dit le droit français

La TMA est un contrat d’entreprise soumis au droit commun. La tierce maintenance applicative est un contrat innommé de prestation de services, qualifié de louage d’ouvrage ou contrat d’entreprise (articles 1710 et 1787 et suivants du Code civil), à titre onéreux et à exécution successive. Il obéit au droit commun des contrats : force obligatoire (article 1103), bonne foi dans la négociation comme dans l’exécution (article 1104) et devoir d’information précontractuelle (article 1112-1 du Code civil), et régime de l’inexécution contractuelle. Faute de régime spécifique, tout se joue dans la rédaction.

Corriger un logiciel suppose un droit d’y toucher. Le prestataire de TMA n’est, par principe, pas l’auteur du logiciel qu’il maintient. Or l’article L. 122-6 du Code de la propriété intellectuelle réserve à l’auteur la reproduction et l’adaptation du programme. L’article L. 122-6-1 du même code autorise, sauf stipulation contraire, la correction des erreurs par la personne ayant le droit d’utiliser le logiciel. Ce droit doit être organisé contractuellement, en donnant au prestataire l’accès aux environnements et au code nécessaires et l’autorisation d’intervenir. [À VÉRIFIER JURISTE : périmètre exact de l’article L. 122-6-1 CPI selon la titularité des droits sur le logiciel maintenu.]

Les évolutions appellent une cession formelle des droits. Ce que le prestataire développe dans le cadre de la maintenance évolutive constitue une œuvre nouvelle sur laquelle il est titulaire des droits d’auteur. Pour que le client en devienne titulaire, une cession de droits d’auteur conforme à l’article L. 131-3 du Code de la propriété intellectuelle est indispensable : chaque droit cédé, son domaine d’exploitation, sa destination, son lieu et sa durée doivent être mentionnés distinctement. À défaut, la cession est inopposable et le client ne peut pas librement réutiliser ce qu’il a pourtant payé.

Les niveaux de service et pénalités engagent le prestataire. Un taux de disponibilité, une garantie de temps d’intervention (GTI) et de rétablissement (GTR), assortis de pénalités, transforment un engagement commercial en obligation mesurable. Ces pénalités peuvent être qualifiées de clause pénale et, à ce titre, être modérées ou augmentées par le juge si elles sont manifestement excessives ou dérisoires (article 1231-5 du Code civil). La qualification de la prestation en obligation de moyens ou de résultat commande par ailleurs la charge de la preuve en cas de défaillance. [À VÉRIFIER JURISTE : qualification moyens ou résultat selon la nature de chaque type de maintenance.]

Les clauses limitant la responsabilité connaissent des bornes. Entre professionnels, un plafond de responsabilité et l’exclusion des dommages indirects sont licites, mais une limitation de responsabilité qui prive de sa substance l’obligation essentielle du prestataire est réputée non écrite (article 1170 du Code civil, dans la lignée des arrêts Chronopost et Faurecia). Elle ne joue pas non plus en cas de faute lourde ou dolosive. Dans un contrat d’adhésion, une clause créant un déséquilibre significatif est neutralisée par l’article 1171 du Code civil, l’article L. 442-1 I du Code de commerce jouant en outre entre partenaires commerciaux.

La rupture et la sortie sont encadrées. La TMA étant une relation établie dont dépend le maintien du logiciel, la rupture brutale appelle un préavis suffisant, sous peine d’engager la responsabilité de son auteur (article L. 442-1 II du Code de commerce). L’absence de clause de réversibilité expose le client à ne pas pouvoir transférer la maintenance à un nouveau prestataire ou la réinternaliser. L’action en responsabilité contractuelle se prescrit par cinq ans (article 2224 du Code civil et article L. 110-4 du Code de commerce).

Ce que contient ce modèle, article par article

Article 1. Objet et périmètre applicatif. L’article fondateur identifie précisément les applications maintenues, leurs versions, leur environnement technique et les composants exclus. Un périmètre imprécis nourrit les litiges sur ce qui relève du forfait et ce qui appelle une prestation complémentaire facturée.

Article 2. Typologie des prestations de maintenance. Le modèle distingue la maintenance corrective (résolution des anomalies), préventive (surveillance et actions d’anticipation), adaptative (mise en conformité avec les changements d’environnement) et évolutive (ajout de fonctionnalités). Chaque catégorie appelle un régime de délais et de facturation propre.

Article 3. Niveaux de service et pénalités. Classification des anomalies par gravité, garantie de temps d’intervention et de rétablissement, plages de service, et pénalités en cas de manquement. Cet article convertit l’engagement de service en obligation mesurable et donne au client un levier en cas de défaillance répétée.

Article 4. Accès aux environnements et support. Conditions d’accès au code source, aux environnements de test et de production, aux comptes et à la documentation, canaux et horaires de support, modalités de remontée des incidents. L’article organise le droit d’intervenir sur le logiciel, condition de faisabilité de la maintenance.

Article 5. Gestion des évolutions. Procédure de demande de changement pour les évolutions hors forfait : chiffrage, validation, planification, recette. L’article distingue clairement la maintenance corrective incluse des développements évolutifs facturés à part.

Article 6. Propriété intellectuelle et cession des développements. L’article organise la cession des droits d’auteur sur les développements spécifiques réalisés, dans le formalisme de l’article L. 131-3 du Code de la propriété intellectuelle, et sécurise le droit du prestataire d’accéder au code aux fins de correction. Il précise le sort des outils et composants préexistants du prestataire.

Article 7. Prix et facturation. Montant du forfait de maintenance, unités d’œuvre pour les prestations hors forfait, périodicité, délai de paiement conforme au plafond de l’article L. 441-10 du Code de commerce, révision éventuelle du prix. Un forfait clair suppose un périmètre lui-même délimité sans ambiguïté.

Article 8. Responsabilité et niveau d’engagement. L’article précise, prestation par prestation, s’il s’agit d’une obligation de moyens ou de résultat, fixe un plafond de responsabilité et exclut les dommages indirects, en restant dans les bornes des articles 1170 et 1231-1 du Code civil. Il rappelle l’exigence d’une assurance responsabilité civile professionnelle.

Article 9. Confidentialité. Chaque partie protège les informations sensibles reçues de l’autre. Le prestataire accède au code, aux données et au fonctionnement interne de l’application, ce qui justifie une obligation ferme, distincte des mesures de sécurité techniques.

Article 10. Protection des données personnelles. Lorsque les interventions donnent accès à des données personnelles, l’article renvoie à un acte de sous-traitance conforme à l’article 28 du RGPD : instructions documentées, mesures de sécurité, encadrement des accès et sort des données consultées.

Article 11. Durée, résiliation et réversibilité. Durée de la maintenance, conditions de reconduction et de résiliation pour faute ou pour convenance avec préavis, puis organisation de la sortie : documentation à jour, transfert de connaissance, restitution des accès et des données. Cet article protège le client contre une dépendance excessive envers son prestataire.

Article 12. Droit applicable et litiges. Droit français, langue du contrat et attribution de juridiction, le cas échéant précédées d’une étape de règlement amiable.

Les pièges à éviter

Reprendre une application sans en auditer l’état. Accepter de maintenir un logiciel sans état des lieux initial expose le prestataire à répondre de défauts hérités du passé, et le client à découvrir tardivement une dette technique non couverte. Un audit de reprise, annexé au contrat, fixe la base à partir de laquelle les obligations de correction commencent réellement à courir.

Confondre maintenance corrective et évolutive. Traiter toute demande comme incluse dans le forfait, sans distinguer la correction d’une anomalie de l’ajout d’une fonctionnalité, brouille l’économie du contrat. La gestion des évolutions doit encadrer par une procédure claire ce qui est facturé en sus, faute de quoi chaque partie tirera la frontière à son avantage.

Négliger la cession des droits sur les évolutions. Payer un développement évolutif sans clause de cession conforme à l’article L. 131-3 du Code de la propriété intellectuelle laisse le client sans droit d’exploitation opposable sur ce qu’il a financé. La mention distincte de chaque droit cédé, de son domaine, sa destination, son lieu et sa durée n’est pas une formalité : son absence rend la cession inopposable.

Fixer des pénalités sans réfléchir à leur qualification. Des pénalités de SLA très élevées ne protègent pas mécaniquement le client : qualifiées de clause pénale, elles peuvent être réduites par le juge si elles sont manifestement excessives (article 1231-5 du Code civil). Un montant proportionné à l’enjeu réel du service résiste mieux qu’un plafond dissuasif mais irréaliste.

Oublier la réversibilité et le transfert de connaissance. Un contrat qui ne prévoit ni documentation à jour, ni transfert de compétence, ni restitution ordonnée des accès en fin de relation laisse le client captif de son prestataire. La réversibilité s’organise à l’avance, pas au moment où la relation se dégrade et où le nouveau prestataire attend les clés.

Piloter directement des intervenants mis à disposition. Lorsque la maintenance est assurée par des personnes que le client encadre au quotidien, sans engagement de résultat du prestataire, le montage peut basculer dans le prêt de main-d’œuvre illicite et le marchandage (articles L. 8241-1 et L. 8231-1 du Code du travail). La TMA au forfait suppose que le prestataire conserve la direction technique de ses équipes. [À VÉRIFIER JURISTE : applicabilité de la loi du 31 décembre 1975 et du régime du prêt de main-d’œuvre selon le montage.]

Comment adapter ce modèle à votre situation

Quelques champs se renseignent systématiquement : l’identité des parties, le périmètre applicatif exact, le prix et ses modalités, la durée de la maintenance. Le reste du texte convient à la plupart des situations de maintenance externalisée courantes.

Le périmètre et la typologie des prestations méritent le plus grand soin. C’est là que se joue la frontière entre ce qui est inclus dans le forfait et ce qui se facture en supplément. Décrivez précisément les applications, leurs versions et leur environnement, et rattachez chaque catégorie de maintenance à un régime de délais et de facturation propre. Un audit de reprise annexé au contrat sécurise le point de départ des obligations.

Le niveau d’engagement s’ajuste selon la criticité de l’application. Pour un logiciel dont dépend une chaîne de production ou un service client, fixez des délais d’intervention courts, un taux de disponibilité élevé et des pénalités dissuasives mais proportionnées. Pour une application interne non critique, un engagement de moyens et des délais plus souples suffisent. Précisez, prestation par prestation, si l’engagement est de moyens ou de résultat.

Adaptez enfin les clauses de propriété intellectuelle et de données au contenu réel du contrat. Une maintenance purement corrective n’appelle qu’un droit d’accès au code aux fins de correction ; une maintenance évolutive impose une cession de droits complète sur les développements. Dès que les interventions donnent accès à des données personnelles, l’acte de sous-traitance conforme à l’article 28 du RGPD n’est pas optionnel.

Ce que ce modèle ne remplace pas

Un modèle est un point de départ, pas un avis. Il ne connaît ni l’état technique réel de l’application maintenue, ni la nature exacte des données traitées, ni le rapport de force entre les parties. Trois situations appellent une relecture par un professionnel : une reprise de maintenance sur un logiciel critique dont l’état initial est incertain, qui justifie un audit et des réserves adaptées ; un montage où des intervenants sont mis à disposition et pilotés par le client, qui appelle une analyse du risque de prêt de main-d’œuvre illicite ; et une maintenance évolutive substantielle, dont les enjeux de propriété intellectuelle et de qualification (moyens ou résultat) doivent être arbitrés au cas par cas.

C’est la raison pour laquelle ce modèle signale ses propres limites, plutôt que de se présenter comme suffisant en toute circonstance.