France: The Responsibilities Of Computer Service Providers Under French Law

Unlike in other economic sectors, bugs seem to be generally tolerated by businesses and consumers in the computing world. This may seem surprising, as computers have grown to become the economy's cornerstone in so-called industrial countries. As a consequence, it is reasonable to wonder if those anomalies are inevitable. Are computer service providers incapable of implementing methods leading to efficient results?

This article is aimed at insisting on the need for a qualitative approach to software development which, if implemented, would help clarify the obligations of the contracting parties.

1. A QUALITATIVE APPROACH

Such a qualitative approach must be undertaken both at the drafting and the developmental levels.

1.1 The drafting of the specifications

The qualitative approach could make use of standardized tools for setting the specifications.

Indeed, the specifications are the needs as expressed by the client and reformulated by the computer service provider.

However, the client generally encounters difficulties in expressing his or her needs in a precise form. Those needs are evaluated in "business" terms and can therefore prove to be incomplete, ambiguous, or unstructured.

At the same time, the computer service provider is in charge of translating the client's needs in terms that can fully describe the expected capacities of the software to be developed. In this respect, the computer service provider is responsible for the quality and coherence of the specifications. This task can be complicated by the language used, which can prove to be too incomplete for such technical topics.

Yet, when we compare the drafting of specifications to an architectural project, we realize that the former lacks rules or norms that would be compulsory for all parties involved. An interesting solution would be to use such norms. A tool for standardized representation could be used, such as UML (Unified Modelling Language), which is a language for modelling that facilitates the design and description of software. Such language is derived from methods such as Booch or OMT.

Continuing in the same stream of ideas, the specifications could be divided into two parts. The first part would describe the functionalities of the application, i.e. the translation of the client's needs in a standardized language. This part would correspond to the architect's plans. As far as the second part is concerned, it would describe the non-functional constraints, such as technical, security or response time, constraints.

It quickly becomes evident that the drafting of the specifications is a service in itself.

Therefore, the question arises of knowing who will be responsible for the drafting of the specifications. If a comparison is made with the architectural project, it is not the architect who is responsible for the building. Does the provider in charge of developing the project have to decide the rules he or she will have to abide by?

1.2 The software development

The provider should be in a position to unveil his development methods. This process goes through stages *which are familiar to computer engineers. Such stages are the definition of each intervening party's role and responsibilities, the gathering and analyzing of the needs as expressed by the client, the designing, the programming itself, the tests, the validation and the launch.

According to some, those steps hinder the whole process. However, such steps are important for controlling the development of the software and implementing more stringent measures. Those steps avoid the often inevitable insufficiencies in the specifications, project modifications, delays and malfunctioning that need repair and increase the costs.

From a legal perspective, more precision leads to a clarification of the parties' respective obligations.

2. LEGAL CONSEQUENCES: A CLARIFICATION OF THE PARTIES' OBLIGATIONS

2.1 The obligations of the provider to advise the client and of the client to collaborate

(a) The obligations of the provider to advise the client and of the client to collaborate

Constant case law indicates that the computer service provider must inform and advise the client.

However, the client should not remain inactive as he must, pursuant to case law, determine his real needs and the means to achieve them. It is said that the client is obliged to cooperate and participate in the elaboration of the project.

Therefore, which of the two parties will under such conditions be considered not to have fulfilled its obligation if the specifications were lacking or proved to be insufficient?

(b) Who is responsible if there are no specifications or if the specifications are insufficient?

Courts have been asked the question of knowing who is responsible in the event the software development project fails and the specifications prove to be lacking or insufficient. There is some fluctuation in the case law; however, courts seem to be favorable to computer service providers.

Such case law, which is hard on end users, tends to forget that the client seldom has the skills necessary for drafting coherent and precise specifications.

In this respect, it must be noted that case law regarding the duty to advise incumbent upon contractors in the construction field is much more stringent in comparison with the duty to advise of computer service providers. Indeed, in the construction field, the contractor must advise the project owner, who is not necessarily an expert in the construction field. The contractor must direct the attention of the project owner or the architect to the flaws in the plans. The contractor must also provide information to the project owner with respect to the potential risks involved and proceed with the necessary verifications before beginning the works. Consequently, the party defaulting in respect of its duty to advise is the one that contents itself with inaccurate information given by its client. Likewise, the contractor, while bound by his professional qualification to advise the project owner, would not be able to eschew his responsibility by pleading a design flaw appearing in the plans.

Why is it that the stringency required from contractors is not required from computer service providers, at a time when the information society is inevitably building itself up?

Case law should rule as a matter of principle that the computer service provider must assist the client in the definition of his or her needs and participate in their clarification. Reinforcing the provider's duties should not mean that the client's duty to collaborate will disappear. Active collaboration from the client in the various steps of development of the software and of implementation of the system is obviously crucial to the success of the project. The client's negligence in his or her checks, or in a rashly pronounced intermediate technical approval, for instance, could not be held against the computer service provider.

The specifications are an essential element in the success of the software development project. The provider has the obligation to help the client in the elaboration of such project or to advise the client to turn to an outside counsel, on the basis of the duty to advise that is incumbent upon the provider.

These specifications are also necessary for the project to succeed legally inasmuch as they constitute a reference point for any potential litigation. They permit a precise definition of the contractual provisions, thereby enabling an assessment of whether the service provider had indeed delivered what had been agreed upon.

2.2 The provider's duty to deliver

The distinction under French law between the obligation de moyens (roughly, duty to use all reasonable efforts to achieve a specific result) and the obligation de résultat (roughly, duty to achieve a specific result) is commonplace in computer law. If the provider is only supposed to use all reasonable means to achieve a goal commonly agreed, the creditor will only obtain damages if he proves the provider's fault in not achieving that goal. On the contrary, if the provider has committed himself to achieve a particular result, the provider will be responsible if the result is not achieved, unless he can prove the existence of force majeure.

This question is closely linked with another question, which is the question of knowing whether the provider has correctly delivered what has been agreed upon, and hence to know the contractual provisions concerning the expected performances of the software. Such contractual provisions must have been stipulated in the contract, and the performances must have been promised. Consequently, the contract should be precise and firm and should be drafted on the basis of clear and complete specifications.

The provider's obligation does not stem from the very nature of the computer contract but from the definition of its object and of the commitments undertaken thereby. The determination of precise results that need to be achieved is also a guarantee for the provider, in case the client changes his initial requests. If no precise results are agreed upon, the duty of the provider will be one to make all reasonable efforts to achieve the result. This leaves the door open to all sorts of factual conflicts and to the risk that the client will have to bear the consequences of the failure of the project, for not having observed his duty to collaborate..

As a conclusion, it could be asserted that a correct definition of the client's needs is a vital prerequisite to the success of a software development project. Beforehand, such definition helps give the software development a quality and increase the efficiency of the software delivered, for the benefit both of the provider and the client

Afterwards, in case of a failure in the system, the parties will be provided with a frame of reference in order to best determine who should bear such failure.

Lastly, the chain of responsibilities is complex because of the multiplicity of parties involved in a software development project. More transparency appears necessary for establishing the relevant liabilities.