Messages les plus consultés

jeudi 4 mars 2021

Formaliser son projet informatique pour limiter les contentieux


Trop de projets informatiques ignorent encore le formalisme de la contractualisation et de la documentation des différentes étapes du projet, qu’il s’agisse d’un projet de développement “classique” ou d’un projet de développement “agile”.


Deux récents jugements viennent ainsi rappeler que l’absence d’expression des besoins et l’absence de contestation des dysfonctionnements avant la réception du projet lèsent le client, malgré l’obligation de conseil incombant au prestataire.


1. L’absence d’expression des besoins par le client dans le cadre d’un projet agile

Dans une première affaire, jugée le 7 octobre 2020, la société Oopet, une startup dans le domaine des animaux de compagnie, avait commandé le développement de deux applications mobiles et d’un site web à la société Dual Media Communication, prestataire informatique. Le client a par la suite reproché au prestataire d’avoir notamment manqué à son obligation de conseil pour ne pas lui avoir recommandé de réaliser un cahier des charges, et d’avoir livré des prestations défectueuses. (1)

Le projet était mené selon la méthode agile. Plus pragmatique et évolutif qu’un développement selon les méthodes classiques en cascade ou en V, un projet agile suit une construction au fur et à mesure sur la base d’itérations, d’intégrations ou de tests en continu (suivant les méthodes agiles “scrum”, “extreme programming” ou “lean software development”).

Quelle que soit la méthode de développement utilisée, un projet agile repose sur une très forte implication des parties - prestataire et client, dans le suivi du projet, nécessitant de nombreux échanges entre les parties et la prise en compte des besoins du client par le prestataire tout au long de la phase de développement informatique.

En l’espèce, le client n’avait pas produit de cahier des charges. Les juges n’ont pourtant pas considéré que le prestataire avait manqué à son obligation de conseil et de mise en garde. Les juges ont en effet pris en compte les particularités d’un projet agile, en soulignant que les difficultés rencontrées pendant la phase de développement, notamment “les erreurs relevées, les réponses quelque fois tardives, la difficulté de s’accorder sur des prestations qui apparaissent entre les cocontractants, ne dérogent pas à la norme de ce type de construction en l’absence de cahier des charges et ne présentent pas de caractère anormal.”

Même s’il n’existe pas de cahier des charges exhaustif au commencement d’un projet agile, ce qui est l’essence même de la flexibilité requise, il est important que le client détaille a minima la finalité du projet et ses attentes (exigences formelles par exemple) afin que le prestataire comprenne ses besoins. Les juges rappellent ainsi que si l’obligation de conseil à la charge du prestataire dépend des besoins et objectifs du client, celui-ci doit les exprimer précisément. Cette obligation ne pourra être exécutée si le client ne fournit pas les informations nécessaires au prestataire afin de lui permettre de répondre au plus près aux besoins du client.

Bien qu’il existe peu de décisions judiciaires relatives à l’exécution de projets agiles - les litiges étant souvent résolus à l’amiable, l’un des problèmes récurrents de ces projets est une défaillance de formalisme : contrats mal rédigés ou inadaptés à ce type de prestation, absence de définition des besoins, coût du projet mal anticipé… Or, même si agilité rime avec souplesse et adaptabilité, les parties se doivent de prendre soin d’encadrer le projet en amont et de respecter les procédures prévues pour chaque phase afin d’éviter les contentieux en bout de course.


2. Les conséquences juridiques de la signature du procès-verbal de recette

L’absence de formalisme dans la relation contractuelle se constate également après la livraison de la prestation, qu’il s’agisse d’un projet développé selon une méthode classique ou agile.

Contrepartie de l’obligation de délivrance par le prestataire, l’obligation de réception incombe au client. Or, la mise en production d’un logiciel ou d’un site web par le client, sans avoir signé de procès-verbal de recette et sans avoir relevé de dysfonctionnements, équivaut à l’acceptation de la prestation.

La phase de réception doit permettre d’identifier par le biais de tests, les dysfonctionnements pouvant subsister dans le logiciel livré. La recette définitive actée emporte l’obligation pour le client de payer le solde de la prestation et, le cas échéant, le départ de la période de garantie contractuelle.

La mise en production ou la signature du procès-verbal de recette sans réserves met un terme au projet informatique. Sauf exception, le client ne peut alors plus contester la délivrance conforme du projet informatique.

Deux décisions récentes rappellent l’importance des phases de livraison et de recette d’un projet informatique.

Dans une affaire opposant la société My Taylor is Free, qui réalise et vend des costumes sur mesure et prêt à porter, à ses prestataires, le client avait conclu un contrat de développement de site e-commerce avec la société Antadis. Par ailleurs, en avril 2017, My Taylor is Free a accepté le devis proposé par la société Exalt3D pour une prestation de “scan, modélisation et texturage”. Plusieurs factures étant restées impayées à Exalt3D, celle-ci a assigné My Taylor is Free en paiement devant le tribunal de commerce d’Aix-en-Provence. (2)

Le tribunal a retenu que les devis ainsi que l’échéancier de paiement avaient été acceptés par My Taylor is Free. Selon les emails échangés entre les trois sociétés, il apparaît notamment que la société Antadis a bien livré le site internet et que celui-ci a été recetté. L’absence de courrier de réclamation à Antadis sur la livraison du site web indique que My Taylor is Free l’a accepté en l’état. De même, My Taylor is Free n’a émis aucune réclamation écrite à la société Exalt3D sur sa prestation. Le tribunal en conclut que les prestations ont été exécutées et livrées par les deux sociétés prestataires et que les factures doivent être réglées par My Taylor is Free.

Dans l’affaire, opposant Oopet à Dual Media Communication, la société Oopet avait signé le procès-verbal de recette sans réserves. Or, la signature du procès-verbal de recette n’est pas une simple formalité. Comme l’a rappelé le tribunal, “il était de la responsabilité de SAS Oopet de vérifier par test les concordances des fonctions des applications à ses attentes, donc que la signature de ces procès-verbaux de recette montre son acceptation en toute connaissance quand il écrit “le client Oopet reconnaît avoir conduit les vérifications nécessaires et estime le produit livré conforme au devis initial”.


    Il existe une abondante jurisprudence sur l’obligation de conseil et de mise en garde incombant au prestataire professionnel. Or cette obligation doit être examinée en parallèle avec l’obligation de collaboration du client. Ces deux affaires illustrent bien cette obligation qui incombe au client pour tout projet de développement informatique. En effet, le client ne peut rester passif. Il doit communiquer ses besoins au prestataire, se manifester et interagir pendant la durée du projet, l’interroger si nécessaire et remonter les dysfonctionnements éventuels. Un certain formalisme doit donc être respecté, depuis un contrat reflétant les prestations à réaliser et précisant, le cas échéant, la méthode de développement, en passant par un suivi de projet rigoureux, une phase de livraison, une ou plusieurs phases de tests, et enfin la recette définitive du projet, cela pour limiter les risques de litiges pouvant survenir.

* * * * * * * * * * *


(1) T com. Paris, 8é ch., 7 oct. 2020, Oopet c/ Dual Media Communication

(2) T com. Aix-en-Provence, 16 nov. 2020, Exalt3D c/ My Taylor is Free et Antadis


Bénédicte DELEPORTE
Avocat

Deleporte Wentz Avocat
www.dwavocat.com

Mars 2021

Aucun commentaire:

Publier un commentaire