Les litiges entre un prestataire informatique et son client peuvent trouver naissance dans des détails de méthodologie qui prennent toute leur importance quand il faut répartir les responsabilités.
Et souvent, c’est la mission de l’expert judiciaire.
Dans cette affaire, que je romance à titre d’exemple, le contrat est clair : le prestataire s’engage à développer un site web « avec une gestion rigoureuse et transparente en sept étapes » :
- Lancement du projet
- Spécifications fonctionnelles et techniques
- Conception graphique du site
- Prototypage
- Réalisation du site
- Tests d’intégration et de qualification
- Mise en production et lancement du site.
La brochure annexée au contrat de prestation détaille chaque étape, les mérites et le savoir faire du prestataire.
Le problème ici est que le client n’a pas été satisfait du résultat de son prestataire et refuse de payer le solde de la facture, alors que le site web est en ligne et fonctionnel. Le ton est monté, les courriers en recommandé échangés, puis l’affaire s’est retrouvée devant la justice qui a désigné un expert judiciaire pour tirer les choses au clair...
Et me voilà en charge du dossier.
Il est facile d’imaginer un mauvais client qui, quoiqu’il arrive, ne sera jamais satisfait de la prestation qu’il trouve très chère pour un résultat qui sera toujours insuffisant à ses yeux.
Il est tout aussi facile d’imaginer un prestataire qui vend très chère une prestation basique à un client ignorant des choses techniques, certaines affaires récentes mettent même en avant des sommes considérables englouties dans des développements web où les difficultés techniques sont sans rapport avec les montants facturés...
Cette différence de connaissances entre un prestataire et son client se traduit par des obligations pour le prestataire. Elles sont principalement de deux types : l’obligation de conseil et l’obligation de renseignement.
D’après le « Lamy informatique et réseaux », l’obligation de conseil du professionnel informatique s’inscrit dans une obligation plus large qui est l’obligation d’information. Cette dernière suppose, outre l’obligation de conseil, une obligation de renseignement et une obligation de mise en garde.
Par exemple, certains fournisseurs n’hésitent pas à insérer dans leurs contrats informatiques une clause stipulant que :
« Le client est conscient que le projet informatique qui va être développé entre les parties au sein de son entreprise est complexe et qu’il est susceptible de remettre profondément en cause son organisation et ses méthodes de travail, ainsi que la qualification du personnel et suppose une collaboration étroite entre les parties, un dialogue permanent dans un esprit de confiance et de respect mutuel. »
Le prestataire doit donc, pour se dégager de toute responsabilité, attirer l’attention du client sur les contraintes d’utilisation du système, les exigences de l’environnement du système et de toutes les difficultés éventuelles auxquelles le client pourra faire face durant les phases de démarrage et d’utilisation du système.
Le devoir de conseil est renforcé lorsque le client est profane ou peu expérimenté, ainsi que le rappelait déjà la cour d’appel de Paris en 1983 : « (…) ce devoir étant d’autant plus rigoureux que les clients sont mal informés en la matière ».
C’est particulièrement flagrant lors du déroulement de la procédure de recette.
Lors des débats, le prestataire a affirmé que « la mise en ligne du site vaut quasiment (sic) pour acceptation de la recette, puisque le site devient dès lors visible au public », puis ensuite que « le site est en ligne et fonctionne, il est donc officieusement (sic) en phase de maintenance ».
Je ne suis pas de cet avis, car s’il est en effet courant de mettre un site internet en ligne alors qu’il est toujours en phase de développement, pour la simple raison qu’il faut faire des tests en « grandeur nature », l’usage est de mettre les codes sources du site sur un serveur dit « de pré-production », avec une adresse web provisoire, commençant par exemple par www4, et paramétré pour ne pas être indexé automatiquement par les moteurs de recherche, pour éviter qu’il ne soit utilisé par les internautes. Le site est donc en ligne pour subir des tests en condition réelle de fonctionnement, avec comme objectif de faire valider le travail par le client. Le fait qu’il soit en ligne et qu’il « fonctionne », ne signifie pas non plus qu’il est en phase de maintenance. Il manque la recette par le client.
L’obligation de réception qui pèse sur le client est la contrepartie de l’obligation de délivrance qui pèse sur le prestataire informatique. Cette obligation de réception existe dans tous les contrats informatiques, qu’ils aient pour objet la vente ou le louage d’un matériel, d’un système informatique, la fourniture d’un logiciel ou d’une prestation informatique. Elle est importante notamment du fait que son exécution conditionne généralement ensuite le paiement du prix (CA Paris, 13 mai 1981, Sté ICL c/ Sté provencale de surveillance, Juris-Data, n°22752), qui est une des obligations majeures du client.
Pour satisfaire à son obligation de réception, le client met généralement en œuvre une procédure convenue à l’avance avec son cocontractant et que l’on dénomme « procédure de recette ». Les modalités de sa mise en œuvre par le client varie cependant suivant les contrats et la nature des livrables.
Lorsqu’il s’agit d’effectuer la recette d’un matériel informatique, le client doit généralement établir un procès-verbal de réception qui atteste que le matériel livré paraît conforme à ce qui avait été commandé. Les choses deviennent plus complexes lorsqu’il s’agit pour le client de prononcer la recette d’un logiciel spécifique. Il est alors usuellement pratiqué un processus de recette en deux étapes successives : une recette provisoire, suivie d’une recette définitive.
La recette provisoire correspond à la phase initiale de vérification du livrable à satisfaire aux spécifications du contrat (la recette provisoire d’un site web est en générale effectuée en ligne sur le serveur de pré-production), tandis que la recette définitive, qui intervient ultérieurement, permet de vérifier le bon fonctionnement du logiciel ou du système en service régulier (c’est-à-dire, comme dans la terminologie des marchés publics, dans des conditions proches de l’activité opérationnelle, et, en l’espèce, en ligne, sur le site définitif de production).
Toute difficulté considérée par le client comme affectant l’aptitude du logiciel ou du système doit faire l’objet d’une réserve accompagnée de fiches d’anomalies remises au prestataire (voir not. Bitan H., Contrats informatiques, Litec, 2002, n°21). Si les anomalies constatées sont particulièrement bloquantes (c’est-à-dire qu’elles empêchent toute mise en œuvre suffisante du logiciel ou du système durant la phase de recette définitive), le client peut aussi surseoir à prononcer la recette provisoire tant que ces anomalies ne sont pas corrigées.
On voit donc bien que la simple mise en ligne d’un site web et son accès (supposé) au public, ne peuvent pas suffire à justifier l’acceptation de la recette du site (et encore moins tacitement).
Il importe donc que le prononcé de cette recette soit mûrement réfléchi. En cas de difficultés techniques particulières ou d’un niveau d’anomalie trop important, il est prudent pour le client de refuser de prononcer la recette définitive et de réclamer une nouvelle période de tests de validité, voire de réclamer après deux recettes manquées, la réécriture de tout ou partie de l’application, sous peine de demander la résiliation du contrat aux torts du fournisseur.
Je vois trop souvent des dossiers où le client fait une confiance aveugle à son prestataire en refusant de réfléchir sur les aspects pourtant basiques relevant d’une gestion de projet informatique. Certes le prestataire est un sachant technique, mais le client doit prendre sa part dans la gestion de projet, et une bonne procédure de recette en fait partie. Ce que ne peut ignorer le prestataire.
Quot homines, tot sententiae
Autant d’hommes, autant d’opinions
Térence, Le Phormion, v. 454
