The growing digitalisation of organisations is creating an ever-stronger dependence on business applications. Corporate websites, customer portals, ERP, CRM or internal tools: all rest on software components that must be maintained, secured and developed. That is precisely the role of TMA, or tierce maintenance applicative (third-party application maintenance), an essential arrangement whose contractual dimension is often poorly understood. Behind an apparently technical term lies a demanding operating model in which responsibilities, commitments and risks must be tightly framed if the information system is to perform. In this context, IT contract management adds real value, by bringing structured, transparent and durable governance to these often complex contracts.
I. Understanding the fundamentals of TMA
TMA is a mechanism by which an organisation entrusts the maintenance of a website, an application or a set of applications to an external supplier. It rests on three broad types of maintenance, and understanding them is indispensable if the contract and the resulting obligations are to be structured properly.
a. Preventive maintenance, the guarantee of operational stability
This is perhaps the least visible part of maintenance, but it is no less essential for that. Preventive maintenance aims to secure the application and to prevent malfunctions from arising. It covers, for example, updating technical components, anticipating version upgrades, finding alternatives to modules that are no longer maintained, optimising performance and reducing security risks. In practice, preventive maintenance is often underestimated, or even relegated to second place, when it is in fact the best insurance against service interruptions.
Contractually, it requires a clear scope, defined deliverables and a stated frequency of execution, without which it becomes theoretical (sometimes a fixed fee billed with no real consideration in return) and loses all substance.
b. Corrective maintenance, the pillar of the TMA contract
Corrective maintenance is the most immediate dimension of TMA. It consists of dealing with faults that occur in production. In a well-drafted contract, every fault must be classified according to predefined categories (typically minor, major or blocking faults). This classification is anything but anecdotal: it drives the supplier's response times, the way incidents are prioritised and, in some cases, the penalties that apply if those times are exceeded.
An imprecise definition inevitably opens the door to divergent interpretations and disputes, hence the need for extremely rigorous contractual framing, based not on dogma but on the needs, maturity and expectations of an organisation.
c. Evolutionary maintenance, a source of high-impact issues
Evolutionary maintenance, lastly, is the strand devoted to developing the application. It covers functional changes, the addition of new components and adaptation to emerging business needs. Its particularity is that it does not generally fall within the base fixed fee, or at any rate is framed on the basis of assumptions (work units, or unités d'œuvre, or sub-fees by level of complexity). It therefore gives rise to additional quotations, budget trade-offs and, very often, to discussions about the boundary between evolutionary and corrective work.
These grey areas are one of the main sources of friction between the parties, hence the importance of contract management that pays close attention to how scope is qualified and how requests are traced.
II. The essential clauses of a TMA contract
A well-structured TMA contract goes far beyond a simple table of service levels. It is a complete governance framework, designed to protect the business, to secure the relationship with the supplier and to guarantee continuity of operations. Several structuring clauses play a decisive part in the contract's overall balance.
a. Reversibility, a genuine guarantee of technical freedom
Inbound and outbound reversibility sits at the heart of any TMA contract. Inbound reversibility allows a new supplier to take the application over properly: it presupposes the handover of complete documentation, the transfer of the technical environments, and access to the development tools and to the history of past work. Outbound reversibility, for its part, must ensure that the business can change supplier under good conditions, without any loss of information, performance or ownership over its application estate. Poorly framed reversibility exposes you to a technical, financial and operational dependency that is particularly hard to put right.
b. The definition of faults and its operational consequences
As we touched on briefly in the first section, the classification of faults is one of the cornerstones of the contract. It must be precise enough to remove any ambiguity, and operational enough to reflect the real impact on users. This definition drives the supplier's commitments on response times, restoration times and incident prioritisation.
It also shapes the penalties that apply if commitments are missed. Experience shows that a large share of disputes stems from incidents being wrongly qualified at the outset, hence the need for an explicit, shared contractual framework.
c. Documentation and processes, often neglected but essential
Documentation is an asset in its own right, indispensable to the working of the information system. Yet it is often among the first casualties of operational pressure.
An effective TMA contract requires documentation that is precise, structured, regularly updated and aligned with changes to the application. Without it, no reversibility is possible, no incident analysis is reliable, and no evolutionary maintenance can be carried out properly.
Processes, for their part, must be described clearly enough to leave no room for interpretation, particularly as regards approval routes, escalation arrangements and prioritisation rules.
d. Term, termination and financial conditions
The contractual terms governing duration, termination and renewal must give the business real room for manoeuvre. This is also the stage at which the balance of power is often decided: an overly rigid contract can make exit particularly expensive, while an insufficiently structured contract can lead to abrupt and damaging breaks.
The financial dimension deserves particular attention. TMA fixed fees can conceal significant grey areas, notably over what does and does not fall within the scope covered. Clarifying the scope, how changes are priced and any adjustment mechanisms is essential if budgets are not to drift.
e. Security, an issue that has become a priority
At a time when cybersecurity incidents are multiplying, security clauses must set demanding requirements on backups, hosting, encryption, access policies and business continuity obligations.
For critical applications, these points are non-negotiable. They directly determine how resilient the organisation is to attacks, incidents or disasters. We covered this in detail in this article, but security has become one of the IT contract manager's key playing fields.
f. Performance commitments
Last but not least, let us turn to performance commitments (also known as SLAs, for Service Level Agreements). These SLAs are a substantial part of the contract. They set the expected service level, the availability rate, the response and restoration times, the RPO/RTO targets, the quality of deliverables and the escalation mechanisms. They are what allows the supplier's performance to be assessed objectively, and they give the contract manager a clear framework for managing the relationship.
III. The role of the IT contract manager in TMA contracts
The IT contract manager occupies a central place in the sound performance of a TMA contract. Without going back over the role and importance of the IT contract manager in general terms, it is worth noting that in TMA (as in many other contracts), the CM is involved from the moment the need is defined, supports the building of the contractual relationship, manages commitments during the operational phase and prepares, where necessary, the conditions for a controlled exit. In an environment where information systems are becoming more complex and where TMA is often the backbone of application operations, that contribution is decisive in maintaining a technical, legal and financial balance.
a. Upstream: scoping, sourcing and contracting
The IT contract manager's added value begins with the very first discussions about the scope of the contract. A TMA that is badly scoped from the outset creates a structural risk that will sooner or later materialise during performance. On the buy side, the contract manager helps define the application scope, document the requirements and translate business expectations into contractual requirements. He or she makes sure that the statement of requirements is not merely a technical description, but that it also reflects what is at stake in terms of availability, security, reversibility, documentation, change and governance.
When a tender is launched, the contract manager contributes directly to structuring the file, identifying the sensitive points and drafting the critical clauses. Knowledge of market practice also makes it possible to detect risk areas (overly broad fixed fees, poorly defined performance commitments, ambiguities over intellectual property, absence of escalation mechanisms, and so on). The contract manager then acts as a safeguard, able to anticipate risky situations and to build the indispensable legal and operational protections into the final version of the contract.
On the supplier side, the role is just as strategic. The contract manager analyses the tender pack or specification to assess technical feasibility, the coherence of the commitments requested and the risk of scope drift. He or she identifies the obligations liable to become untenable in performance and alerts the sales and technical teams when certain clauses need to be renegotiated. The contract manager helps build a secure, balanced and realistic bid, taking care not to create structurally disadvantageous commitments.
b. The performance phase: managing the relationship, guaranteeing performance and controlling risk
Once the contract is signed, the IT contract manager becomes the key point of contact, responsible for turning a legal document into a tool of operational governance. On the buy side, he or she oversees the proper application of the contract throughout its term, making sure that service levels (SLAs) are reliably monitored, that incidents are correctly qualified and that response and restoration times are met. The contract manager puts performance dashboards in place, runs steering committees, analyses trends and raises the alarm when drift becomes recurrent. Where commitments are not met, he or she checks that penalties are applied, not out of a punitive logic, but as the normal mechanism of regulation and accountability provided for in the contract.
The contract manager also plays an essential part in managing functional scope. The line between corrective, preventive and evolutionary maintenance is often blurred, and misunderstandings are frequent. The contract manager is the one who qualifies, documents and secures the nature of each request, protecting the buyer from budget drift and the supplier from excessive demands. The role consists of bringing clarity, recording decisions, keeping a clear register of every request and preventing operational teams from extending the scope "out of habit" or "out of opportunism".
On the supplier side, the IT contract manager protects the balance of the contract just as much. He or she makes sure that out-of-scope requests are properly identified and that a quotation is formalised before any work starts. The contract manager ensures that the volume of evolutionary maintenance (sometimes the economic heart of a TMA contract) is correctly documented and invoiced. He or she also heads off situations where the delivery team makes non-contractual commitments, out of ignorance or a wish to help the client, which can quickly become problematic in terms of workload or liability.
Beyond managing requests, the contract manager also becomes a key player in the client-supplier relationship. He or she facilitates exchanges, structures communication, arbitrates emerging disagreements and heads off disputes before they turn into litigation. Much of the role's value lies precisely in that ability to stop operational frustrations from turning into formal confrontation.
c. End of contract: securing reversibility and preserving the application estate
The lifecycle of a TMA contract does not end when the services stop. It truly ends once reversibility has been carried out fully and in accordance with the contract. The contract manager is then responsible for checking that all the obligations relating to knowledge transfer, the handover of the environments, the transmission of the source code and the documentation, as well as the training of the new supplier or of the internal teams, have been met.
He or she audits the documentation estate, makes sure the development and production environments are fully transferable, checks the consistency of the information provided and guarantees that the incoming supplier has everything it needs to take the application over without any degradation of service. Reversibility is often the moment when the quality of contract management becomes apparent: incomplete documentation, undocumented processes or poorly managed technical debt can prove extremely expensive. The IT contract manager secures this critical stage by anticipating the exit from the first months of performance and by instilling documentary discipline throughout the contract.
Conclusion: contract management, a strategic function in the governance of TMA contracts
Ultimately, the IT contract manager plays a role of constant balance. He or she reconciles contractual logic with operational reality, protects the business against ambiguity, preserves the relationship with the supplier, guarantees continuity of operations and maintains a long-term view of the application estate. In a context where applications are critical, where cybersecurity imposes ever-greater requirements, where organisations are seeking performance gains and where IT budgets must be scrupulously controlled, that role has become absolutely strategic.