Cour d’appel de Paris, 19 mars 2021, RG n°18/20487
En matière de projets informatiques, les juges se montrent particulièrement exigeants vis-à-vis des prestataires, en tout cas pour ce qui est du devoir d’information et de conseil.
En l’espèce, un contrat a été conclu en mars 2011 entre les sociétés Data Gest (spécialisée dans le marketing et les programmes de fidélisation) et 3LI Solutions (intégrateur d’ERP spécialisée dans les produits Microsoft), couvrant trois volets :
- la cession du droit d’utiliser les licences Microsoft Dynamics ;
- des prestations (installation du progiciel et réalisation d’adaptations spécifiques) ;
- des services de maintenance.
En phase de conception, le client avait clairement exprimé son souhait de bénéficier d’interfaces ne générant pas de développements dans le logiciel, précisant qu’il souhaitait se réserver la possibilité de confier la maintenance à un autre partenaire Microsoft.
Un procès-verbal de recette avait été signé en mai 2012 afin de permettre la bascule en production.
En juin 2013, un flux « E-expeditor » (permettant d’acheminer les cadeaux de fidélisation) s’était bloqué. Cet incident n’a visiblement pas été pris en charge par le prestataire au motif que la maintenance n’avait pas été réglée par le client. Le client reprochait en outre au prestataire d’avoir intégré un module d’interface sans son autorisation, lequel semblait être la source du blocage en question.
Le client a dans un premier temps sollicité auprès du juge des référés la remise des codes sources du module. Cette demande avait été rejetée et l’affaire a été renvoyée au fond.
Le Tribunal de commerce de Paris, dans un jugement du 4 juillet 2018, a débouté Data Gest de ses demandes (que ce soit pour la communication des codes sources, le versement d’indemnités, la résolution du contrat de maintenance ou pour sa demande d’expertise judiciaire).
Cette dernière a interjeté appel de ce jugement le 29 août 2018 sollicitant notamment :
- la communication des codes sources ;
- la nullité de l’ensemble contractuel (et, à titre subsidiaire, sa résolution judiciaire) ;
- la condamnation du prestataire à des dommages intérêts.
En premier lieu, sur la qualification du contrat et ses conséquences, le client faisait valoir qu’il s’agissait :
- soit d’un contrat de vente de progiciel, contenant des codes sources sur lesquels la société n’avait pas la propriété, pour solliciter la nullité de cette vente ;
- soit d’un contrat d’entreprise, assorti d’une obligation de résultat.
Sur cette question, la Cour d’appel indique qu’il ne s’agit pas d’un contrat de vente mais d’un contrat sui-generis pour lequel :
- l’obligation de concéder un droit d’utilisation est de résultat ;
- l’obligation d’installer le progiciel est de moyen.
A priori, le contrat en question ne fournissait pas véritablement d’éclairage sur la nature des obligations qu’il contenait.
En second lieu, sur les manquements, le client reprochait au prestataire :
- d’avoir développé un module sans son consentement, ce qui avait entrainé un blocage du flux E-expeditor, alors qu’il avait expressément refusé de nouveaux développements dans les codes sources pour ne pas toucher à la stabilité du progiciel et souhaitait se réserver la possibilité de confier la maintenance à un autre prestataire ;
- d’avoir manqué à son obligation de conseil en lui imposant une solution différente sans jamais l’en informer.
De son côté le prestataire indiquait :
- qu’il s’était loyalement acquitté de son obligation de délivrance ;
- qu’il avait parfaitement informé le client de l’existence du module incriminé, dans la mesure où celui-ci aurait été évoqué :
- dans le contrat de mars 2011, et plus spécifiquement dans l’annexe relative au prix des licences ;
- lors d’une réunion de cadrage de mai 2011 et validé par le client.
- qu’un procès-verbal de recette sans réserve avait été émis par le client, de sorte que la conformité de la solution (incluant ce module) avait été actée par celui-ci (les mentions manuscrites ne pouvant, selon lui, faire office de réserves).
Reprenant les arguments de l’intimé, la Cour d’appel de Paris rappelle que :
- le contrat de licence de mars 2011 ne fournissait aucune information sur ce module, si ce n’est son nom ; de sorte qu’il était impossible pour le client de savoir que ce module était spécialement développé par le prestataire et grevé par ses droits de propriété intellectuelle ;
- le paiement des factures était insuffisant pour permettre de présumer que le client avait donné son accord sur le développement de ce module ;
- le compte rendu de la réunion de mai 2011 ne permettait ni de révéler que ce module était développé par le prestataire, ni que le client avait donné son accord pour la mise en œuvre de ce module.
La Cour d’appel relève en outre que, contrairement à ce qu’indiquait le prestataire, le procès-verbal de recette comprenait, dans la partie « processus interface », une mention manuscrite « en attente de modifications suites dernier test ». Mais surtout, ce procès-verbal de recette ne précisait pas que l’interface allait être assurée par ce module, ce qui, selon la Cour, lui retirait toute force probante quant à la conformité du processus par rapport aux demandes du Client.
Autrement dit, si le client n’est pas éclairé sur ce qu’il est en train de recetter, ou s’il existe une ambigüité sur la teneur des éléments recettés, le prestataire ne peut s’en prévaloir pour affirmer que la conformité des livraisons a été actée par le client.
En conséquence, la Cour d’appel estime que le prestataire a manqué à son obligation de conseil et d’information et qu’il n’a pas respecté les besoins exprimés par le client, de sorte qu’il doit être tenu responsable des conséquences dommageables générées par le module installé.
La Cour fait ainsi droit aux demandes du client et, en raison du caractère indivisible du contrat, indique qu’il y’a lieu de prononcer la résolution de celui-ci et d’ordonner la restitution de l’ensemble des sommes payées.
