First case law on the apportionment of liability in the poor execution of IT contracts using the "Agile" method

The Agile method is a collaborative software development process. Using this model, a client expresses his need to an IT provider, who then "translates" this information into a set of technical specifications, for approval by both parties. The parties also agree on the payment terms and schedule. The development phase is then a cooperative process, with the provider developing the modules and delivering them to the client at regular intervals; the client tests the deliverables and, if necessary, asks for any bugs to be fixed or changes made. In some cases, the contract can be extended after delivery of the software solution, as part of a process of ongoing improvement.

Due to the heavy involvement of both sides in this type of IT contract, the apportionment of liability between the client and the IT provider for any poor execution is a specific issue, which has, to a certain extent, been clarified recently by the courts.

It has therefore been confirmed that an Agile contract is, usually, an IT contract like any other, where the IT provider has a duty of advice to the client, which must be performed continuously throughout the term of the contract. However, the Paris Court of Appeals has stated, in a recent ruling, that the IT provider could not "exonerate itself from its duty of advice by arguing that Agile contracts are jointly managed, because this duty [of advice] had been contractually stipulated" (Paris Court of Appeals, 3 July 2015, No. 13/06963).

In particular, the client must be informed as and when any technical difficulties arise and if there is any risk of the budget being exceeded. Taken the other way around, it appears possible that, in the absence of a contractual clause to that effect, the provider is relieved of all or some of its duty of advice during the execution of an Agile contract. This duty therefore needs to be clearly stipulated in all contracts that are signed.

In addition, in the event of unsatisfactory development, the client would not be able, at the end of the contract, to argue the unsuitability of the software for his needs if he did not previously report any difficulties and concerns following the production of each deliverable by the IT provider. Likewise, if the quality of the interim deliverables is too poor for the client to be able to conduct the necessary tests before feeding back to the provider and guiding the future work, if necessary, this situation must be expressly reported at each milestone (Paris Court of Appeals, 3 July 2015, op cit).

On the other hand, if the IT provider encounters difficulties due to a lack of collaboration by the client, who does not perform the necessary tests on time, it must also specifically say so. In fact, the IT provider's duty of advice means it must inform the other side of any fact or event likely to delay the development of the software. In the absence of any such notification during the term of the contract, the IT provider cannot then accuse the client of inertia after it has ended (Paris Court of Appeals, 1 October 2015, no. 14/07440). Therefore, because this is a collaborative form of contract, any difficulties experienced by either side must be reported promptly, by any reliable and provable method.

Finally, the terms of the contract are especially important. This being a participative process involving numerous uncertainties, the IT Provider cannot be held responsible for any delays in delivery if the contract allows for a "renewable" deadline in undefined circumstances (Paris Court of Appeals, 3 July 2015, op cit). The same applies if the deadline is described in the contract as "provisional" (Paris Court of Appeals, 1 October 2015, op cit). On the other hand, the concept of cut-off date can be used in this type of contract, whereby the arrival of a pre-agreed date automatically halts the contract, unless the parties have signed an extension.

Similarly, for contracts signed on a cost-plus basis i.e. invoiced based on time actually spent developing the software, any clause allowing prices to be downwardly revised but which is insufficiently precise is devoid of any legal effect. Services must be invoiced strictly based on time spent, with no bonus for early delivery (Paris Court of Appeals, 3 July 2015, op cit). If, on the other hand, the invoices exceed the initial budget, the client cannot refuse to pay on the grounds that, as of receipt of the invoice, he is not in possession of a finished product, since this is an inherent aspect of the Agile method. The only way this would not apply is if he could prove that the work was "unsuccessful or faulty" (Paris Court of Appeals, 1 October 2015, op cit), based on an inter partes assessment. The involvement of a new provider and his report would not be sufficient evidence.

In light of these two rulings by the Paris Court of Appeals, whose positioning needs to be confirmed by the other civil jurisdictions, it is important to understand, whenever embarking on a software development project using the Agile method, that this choice of contract will not tolerate any imprecision or inertia by either party. It is up to each side to make sure he fully benefits from this fact.