24

Click here to load reader

Code Sources

Embed Size (px)

Citation preview

Page 1: Code Sources

RDCO2007-4-046Revue des Contrats, 01 octobre 2007 n° 4, P. 1335 - Tous droits réservés

Contrats

La maîtrise des codes sources par le client utilisateur d'un logiciel

Les entreprises, quel que soit leur secteur d'activité, et tout particulièrement les opérateurs de télécommunications, doivent faire face à une dépendance technologique croissante vis-à-vis de solutions informatiques complexes, auxquelles elles recourent pour la réalisation d'une grande partie des tâches nécessaires à leur activité.

En effet, une fois mises en place, ces solutions informatiques, dans la mesure où elles reposent sur des composants logiciels, doivent faire l'objet d'une maintenance continue, que ce soit pour en corriger les erreurs (bogues)1 ou pour en assurer l'adaptation face aux évolutions réglementaires et techniques qui peuvent en affecter l'environnement2.

Or, en pratique, le client utilisateur d'un logiciel ne dispose souvent que d'un droit d'usage limité à sa version exécutable (ou « code objet »), tandis que le fournisseur du logiciel3 conserve seul la maîtrise des « codes sources ».

Le « code objet » est la traduction du logiciel dans un langage (le binaire)4, que seule la machine est capable de comprendre en l'état5. Il est insuffisant pour assurer la maintenance du logiciel, puisqu'il ne permet pas à l'homme de l'art d'en comprendre le fonctionnement ni de le modifier, faute de pouvoir l'appréhender.

Les « codes sources » correspondent pour leur part à la version du logiciel écrite dans un langage de programmation compréhensible par l'homme6. Ils sont indispensables pour comprendre le fonctionnement du programme et donc pour le modifier.

Cette situation peut se révéler très inconfortable pour le client utilisateur d'un logiciel ou d'une solution informatique basée sur des éléments logiciels. En effet, si le fournisseur du logiciel disparaît suite à une procédure collective, cesse son activité ou se montre défaillant dans l'exécution de ses obligations de maintenance, le client, faute de disposer des « codes sources » du logiciel, se trouve dans l'incapacité de procéder lui-même (ou de faire procéder par un tiers) à sa maintenance.

La question de la maîtrise et de l'accès aux codes sources des logiciels est donc essentielle pour tout praticien confronté à la rédaction d'un contrat informatique.

Face au silence des textes et au caractère incertain de la jurisprudence quant à la reconnaissance d'un droit d'accès implicite aux codes sources , le client utilisateur d'un logiciel devra veiller à s'aménager conventionnellement ce droit (I).

En fonction des circonstances et des intérêts poursuivis par les parties en présence, cet aménagement conventionnel pourra, en pratique, prendre différentes formes telles que la cession ou la concession de droits inconditionnels sur le logiciel en code source, la stipulation d'un engagement de remise des codes sources sous conditions, la conclusion d'un contrat d'entiercement spécifique ou encore l'adhésion du client à un programme de séquestre proposé par le fournisseur du logiciel (II).

I - L'absence de droit implicite dévolu au client sur les codes sources du logiciel

A. - L'ineffectivité des textes

Contrairement à la tradition législative française, marquée par une conception synthétique des droits de l'auteur, l'article L. 122-6 du Code de la propriété intellectuelle7 explicite de manière détaillée les droits reconnus à l'auteur d'un logiciel8.

À la lecture de ce texte, on constate que le créateur d'un logiciel bénéficie d'importantes prérogatives patrimoniales d'exploitation, qui lui permettent d'interdire aux tiers la

Page 2: Code Sources

reproduction, l'utilisation, l'adaptation et la commercialisation de son oeuvre, effectuées sans son accord.

Il n'y aura donc rien d'étonnant à ce qu'aucune disposition légale ne prévoie l'obligation pour le fournisseur d'un logiciel d'en communiquer les codes sources à ses clients9.

Néanmoins, une partie de la doctrine10 a pu déduire des dispositions du Code de la propriété intellectuelle le droit de l'utilisateur de connaître le contenu des sources à partir du code objet dont il dispose.

Le cas le plus net paraît être celui de la « décompilation » du logiciel, qui consiste dans la traduction du code objet en code source11 dont l'article L. 122-6-1, IV, n'accorde cependant le droit au client que dans le cas où elle serait « indispensable pour obtenir des informations nécessaires à l'interopérabilité d'un logiciel créé de façon indépendante avec d'autres logiciels ».

L'interopérabilité désignant « la capacité d'échanger des informations sur les principes, méthodes et structures mises en oeuvre par un logiciel quand il interagit avec son environnement logiciel ou matériel »12, on comprendra que la faculté de décompilation offerte par le Code la propriété intellectuelle se limite à des fins assez éloignées des préoccupations d'un utilisateur simplement désireux de corriger les bogues d'un programme.

En tout état de cause, pour que la décompilation puisse lui permettre de disposer de codes sources exploitables, le client devra disposer d'un grand nombre d'informations que, en pratique, seul le fournisseur du logiciel connaît (notamment le compilateur13 utilisé pour générer le code objet à partir des codes sources et le langage de programmation de haut niveau utilisé par le développeur qui n'est pas toujours standardisé).

Quelle que soit la portée des textes, il est donc purement et simplement illusoire de croire qu'il est aujourd'hui techniquement possible, à partir d'une version exécutable d'un logiciel, d'obtenir les codes sources par le simple jeu de la décompilation14.

À l'image du droit de décompiler le logiciel, l'article L. 122-6-1, I, du Code de la propriété intellectuelle a lui aussi pu être interprété dans le sens d'un accès implicite aux sources .

Ainsi, ce texte dispose que « ne sont pas soumis à l'autorisation de l'auteur » les actes de reproduction, traduction, adaptation et d'arrangement, « lorsqu'ils sont nécessaires pour permettre l'utilisation du logiciel, conformément à sa destination, par la personne ayant le droit de l'utiliser, y compris pour corriger des erreurs ».

La question est de savoir si cette disposition pourrait conférer à l'utilisateur un droit d'accès aux codes sources , dans la mesure où ceux-ci sont indispensables à l'exercice des droits de correction et d'adaptation auxquels le texte semble ouvrir droit.

À cette question, E. Montero15 répond par la négative dans le sens où, pour lui, la correction des erreurs est prévue au titre d'une simple exception aux droits exclusifs de l'auteur. Il s'ensuit que l'utilisateur jouirait dès lors d'une simple faculté, et non d'un droit, de procéder à la correction des erreurs.

On comprendra donc que l'analyse des textes n'est pas des plus favorables à la reconnaissance d'un droit implicite du client de disposer des sources du logiciel, les seules dispositions pouvant aller dans ce sens étant particulièrement débattues, lorsqu'elles ne sont pas dépourvues de toute portée pratique.

Face à ce constat, il conviendra de se pencher sur la position du juge en la matière.

B. - L'incertitude jurisprudentielle

La jurisprudence n'est pas beaucoup plus explicite, lorsqu'il s'agit de tenter de reconnaître au client un droit implicite sur les codes sources du logiciel dont il est utilisateur.

En matière de logiciel standard ou progiciel16, le juge, comme une grande partie de la doctrine, considère qu'à défaut de clause contraire, la fourniture d'un logiciel standard n'implique pas automatiquement la délivrance de ses codes sources 17.

Page 3: Code Sources

En effet, les codes sources d'un logiciel standard sont rarement communiqués au client, puisque, soucieux de se réserver l'exploitation du logiciel standard, dont le développement est financé par lui, le fournisseur ne souhaite pas communiquer les codes sources de son oeuvre au risque d'en faciliter le plagiat.

Pour ce qui est des logiciels spécifiques18, des auteurs estiment que le client dispose d'un droit d'accès aux codes sources 19 en tant qu'accessoire de la prestation de développement du logiciel. Le devoir de bonne foi et l'obligation d'information, son corollaire, sont aussi parfois invoqués.

Un arrêt de Cour d'appel a pu conforter, dans un premier temps, cette position doctrinale, affirmant le caractère accessoire des codes sources .20

Cependant, d'autres juridictions sont depuis allées en sens contraire, à l'instar du juge des référés parisien21 et, plus particulièrement, de la Cour de cassation qui a refusé de retenir l'argument suivant lequel la fourniture d'un logiciel spécifique impliquait nécessairement, à la différence des progiciels standard, le droit d'accès à son code source22.

Il semblerait donc que le critère jurisprudentiel de l'accès aux codes sources ne tienne pas tant à la distinction entre logiciel standard et logiciel spécifique, qu'à l'étendue des droits accordés à l'utilisateur sur le logiciel concerné.

En l'absence de disposition conventionnelle, la jurisprudence actuelle tend à refuser l'accès au code source à l'utilisateur qui ne dispose que d'un simple droit d'usage du logiciel standard ou spécifique, sans faculté de le modifier ou de le corriger.

Reste que l'utilisateur qui se serait vu concéder des droits plus étendus sur le logiciel, tels que notamment un droit de modification et/ou de correction (hypothèse que l'on rencontrera le plus fréquemment en matière de logiciels spécifiques), pourra peut-être chercher à soutenir l'existence d'un droit d'accès implicite au code source pour pouvoir exercer ses droits.

On pourra en effet arguer du fait que les codes sources sont moins l'accessoire du développement du logiciel que l'accessoire des droits concédés puisqu'ils sont indispensables à l'exercice de certains droits et notamment des droits de modification et de correction qui pourraient être reconnus au client par le fournisseur du logiciel.

Force est cependant de constater qu'en l'état actuel de la jurisprudence, il est impossible d'affirmer l'existence d'un droit général et implicite d'accès du client au code source d'un logiciel, fût-il spécifique et modifiable par le client.

Une approche pragmatique conduira donc le praticien à conclure, tout comme les professeurs Croze et Saunier23, que la mise à disposition du code source n'est pas un droit de l'utilisateur mais une faculté qu'il faudra veiller à aménager contractuellement.

II - L'aménagement conventionnel d'un droit du client sur les codes sources du logiciel

Nous avons vu qu'il était nécessaire de recourir au contrat pour permettre au client de se ménager un droit sur les codes sources du logiciel dont il est utilisateur.

En pratique, le droit du client sur les codes sources du logiciel pourra être traité de différentes façons selon le contexte et les intérêts économiques ou pratiques des parties en présence.

À défaut de se faire céder ou concéder un droit inconditionnel sur les codes sources du logiciel (A), le client devra chercher à se ménager un droit d'accès aux codes sources dans certaines hypothèses limitativement prévues par la convention qui le lie au fournisseur du logiciel.

Si un tel droit d'accès conditionnel aux codes sources peut prendre la forme d'un simple engagement de remise des codes sources par le cocontractant lui-même (B), nous verrons que pour des raisons de convenance et de sécurité juridique il est toutefois préférable de recourir à l'entremise d'un tiers séquestre (C).

A. - La cession ou la concession au client d'un droit inconditionnel sur les codes sources

Page 4: Code Sources

Dans certains cas, la convention donnant lieu à la remise du logiciel au client pourra directement prévoir le droit pour le client de procéder à la correction ou à la modification du logiciel à partir de ses codes sources .

Si elle présente l'avantage de donner au client une totale maîtrise des sources du logiciel, cette solution pourra se révéler quelque peu inadaptée, s'agissant seulement de préserver les droits du client en cas de défaillance de son fournisseur dans la maintenance du logiciel.

En pratique, cette solution « maximaliste » sera le plus souvent réservée aux développements spécifiques dont le fournisseur n'aura pas de raisons légitimes de vouloir continuer à s'assurer le monopole des droits de modification et de correction et dont le client, qui en aura le plus souvent payé l'intégralité des coûts de développement, voudra en conséquence pouvoir disposer le plus librement possible.

Lors de la mise en place de cette solution, le praticien devra notamment veiller à rédiger avec soin les clauses relatives à l'étendue et la durée des droits cédés ou concédés au client sur le logiciel, en code source comme en code objet, ainsi que sur les éventuelles oeuvres dérivées qui pourront être réalisées par le client dans l'exercice de ses droits.

Bien sûr, chacun des droits cédés ou concédés devra faire l'objet d'une mention distincte dans l'acte, de même que le domaine d'exploitation de ces droits devra être délimité quant à son étendue, sa destination, son lieu et sa durée24.

On veillera plus particulièrement à ce que la convention accorde au client les droits nécessaires pour effectuer la maintenance du logiciel pendant toute la durée de son utilisation et notamment les droits de reproduction, de modification, de correction et d'adaptation du logiciel, par le client lui-même ou par un tiers, prestataire de service du client.

De même, et même si la nature des droits cédés ou concédés pourrait laisser à penser que cette obligation est implicite, la jurisprudence étant silencieuse sur ce point (v. I, B), il sera préférable de prévoir expressément l'obligation pour le fournisseur de remettre au client les codes sources du logiciel, accompagnés, le cas échéant, de l'ensemble des informations nécessaires pour en permettre l'exploitation par l'homme de l'art.

En effet, comme le rappellent justement les professeurs Croze et Saunier25, pour être utilisables dans de bonnes conditions, les codes sources d'un logiciel doivent s'accompagner d'un grand nombre d'informations techniques (paramètres de compilation, modes opératoires d'analyse, listing des programmes, etc.) que l'on gagnera, le cas échéant, à lister au contrat comme faisant intégralement partie des livrables attendus du fournisseur du logiciel lors de la remise des codes sources .

On pourra, à ce titre, recourir à la clause suivante :

« Le fournisseur s'engage à remettre au client, selon les modalités définies en annexe, l'ensemble des codes sources et des codes exécutables afférent au logiciel.

Lesdits codes sources du logiciel seront remis au client accompagnés de l'ensemble des éléments de documentation définis en annexe et plus généralement de l'ensemble des informations nécessaires pour en permettre l'exploitation par tout homme de l'art ».

On pourra de même prévoir que la remise des codes sources du logiciel puisse s'accompagner de prestations de services spécifiques visant à transférer au client les compétences nécessaires pour lui permettre d'exploiter au mieux les codes sources du logiciel. Une clause de réversibilité du programmeur au mainteneur, en quelque sorte.

B. - L'engagement de remise des codes sources par le cocontractant lui-même

Dans le cas où il ne bénéficiera que d'un simple droit d'utilisation du logiciel en code objet, le client gagnera néanmoins à se ménager un droit d'accéder à ses codes sources , dans certaines circonstances.

Le praticien se verra ainsi parfois proposer la mise en place d'une stipulation, souvent minimaliste, par laquelle le fournisseur du logiciel s'engage à remettre au client les codes sources du logiciel ainsi qu'à lui en concéder le droit d'usage, dans certains cas de défaillance

Page 5: Code Sources

du fournisseur, limitativement prévus à la convention, cas qu'il conviendra d'ailleurs de rédiger et négocier avec le même soin que les « cas d'ouverture » d'un contrat de séquestre (v. C).

Une telle proposition émanera le plus souvent d'un cocontractant soucieux de s'affranchir de la nécessité de mettre en place un mécanisme de séquestre, voire de préserver la confidentialité totale de ses codes sources , y compris à l'égard des tiers séquestres26.

Si elle présente l'avantage de la simplicité et de la gratuité (pas besoin de déposer les codes sources auprès d'un séquestre ni de négocier un contrat d'entiercement), force est de constater qu'une telle clause (qui repose sur le seul engagement unilatéral du fournisseur) n'offre qu'une sécurité juridique très relative.

En effet, outre les limites liées au fait qu'il s'agit d'une obligation de faire (insusceptible d'exécution forcée27), cette disposition se révélera bien souvent inefficace en pratique face à un cocontractant ayant fait l'objet d'une liquidation judiciaire ou n'ayant jamais pris soin de garder un exemplaire exploitable, « à jour » et documenté des codes sources qu'il s'était pourtant engagé à conserver et remettre.

Il n'en reste pas moins qu'à défaut d'offrir un degré élevé de protection des intérêts du client, notamment face à un fournisseur à la santé financière fragile, cette disposition minimaliste pourra néanmoins, dans certains cas, constituer un fondement pour permettre au client d'obtenir du juge qu'il condamne son cocontractant à lui remettre sous astreinte les codes sources d'un logiciel après avoir constaté la réalisation des conditions prévues à la convention pour ouvrir droit à la remise des codes sources au client.

C. - L'entiercement

Comme nous l'avons vu et même s'il n'est pas sans portée juridique, le simple engagement conditionnel du fournisseur de remettre les codes sources au client connaît des limites pratiques quant à sa mise en oeuvre, principalement en cas de disparition du fournisseur ou de négligence de ce dernier dans la conservation des codes sources .

Pour remédier à ces limites tout en respectant les objectifs poursuivis par les parties en présence, on aura usuellement recours à un mécanisme contractuel désormais bien connu dans le monde informatique : l'entiercement28.

Il s'agira de déposer les codes sources du logiciel auprès d'un « tiers de confiance » chargé de veiller à leur conservation et de les remettre promptement au client dans certaines hypothèses précises caractérisant la défaillance du fournisseur du logiciel.

La mise en place de ce mécanisme donnera le plus souvent lieu à la conclusion d'une convention de séquestre spécifique entre le client, le fournisseur du logiciel et le tiers de confiance, laquelle aura vocation à régir l'ensemble des relations entre ces trois parties dans le cadre du dépôt, de la conservation et, le cas échéant, de la remise des codes sources du logiciel.

Toutefois, et afin d'éviter de multiplier les conventions de séquestre spécifiques, de très nombreux éditeurs de logiciels standard ont pour pratique de conclure un contrat de séquestre unique, au bénéfice de l'ensemble des clients utilisateurs des logiciels qu'ils commercialisent.

Dans la première hypothèse, le praticien devra non seulement veiller à rédiger et négocier avec soin la convention de séquestre tripartite, mais aussi s'attacher à bien choisir le séquestre avec lequel elle aura vocation à être conclue (1.).

Dans la seconde hypothèse, le praticien devra faire preuve d'une grande vigilance pour s'assurer de l'efficacité, voire de l'effectivité du mécanisme de séquestre qui lui est proposé (2.).

1. Les enjeux liés à la mise en place d'une convention de séquestre tripartite

La mise en place une convention de séquestre tripartite suppose en premier lieu que l'on choisisse un tiers séquestre.

Page 6: Code Sources

Sur ce point, si la convention de séquestre peut être conclue avec tout tiers, elle revêt à l'évidence un très fort caractère intuitu personae. On veillera donc à choisir un tiers ayant la confiance des parties ou tout du moins vocation à faire preuve d'une probité sans faille.

Ainsi, le dépôt du logiciel peut par exemple être effectué auprès d'un huissier de justice, d'une banque, ou d'un notaire.

Cependant, si la confiance est un critère déterminant, la compétence du tiers séquestre ne devra pas en être négligée pour autant.

En effet, le séquestre n'a d'intérêt que si les codes sources déposées correspondent effectivement au code objet du logiciel tel qu'il est utilisé par le client.

Dès lors, on gagnera à confier la prestation de séquestre à un prestataire spécialisé qui dispose des compétences et des moyens nécessaires pour effectuer un contrôle la conformité des codes sources qui lui sont remis.

En France, il existe très peu de prestataires véritablement spécialisés dans le séquestre de logiciels qui soient capables de proposer de telles prestations de contrôle de conformité. On citera cependant les deux principaux que sont l'Agence pour la protection des programmes (APP)29 et la société Logitas SA30.

Une fois le séquestre choisi, il faudra s'attacher à rédiger et négocier avec soin la convention de séquestre.

Si la liberté contractuelle est de mise en la matière, notamment pour ce qui concerne les modalités financières (les frais de séquestre pourront le cas échéant être supportés par l'une ou l'autre des parties, voire par les deux parties), certains fondamentaux devront impérativement être abordés dans la convention.

En premier lieu, on veillera à définir avec soin le logiciel ainsi que les éléments de documentation ou informations indispensables à l'exploitation des codes sources du logiciel (v. A) qui devront être remis au séquestre avec les codes sources .

L'on définira également, en second lieu, les modalités de remise des codes sources au séquestre. Il faudra notamment, à ce titre, prévoir l'obligation pour le fournisseur du logiciel de procéder au dépôt des codes sources des évolutions apportées au logiciel au cours de l'exécution du contrat qui le lie au client, notamment lorsque ce dernier prévoit la fourniture de mises à jour, nouvelles versions ou autres correctifs de maintenance. En effet, seule la version « à jour » des codes sources du logiciel présente un intérêt pour le client puisque c'est cette version qu'il utilise et doit donc être capable de maintenir.

On pourra à cet effet recourir à la clause suivante :

« Le fournisseur s'engage à déposer, à ses frais, auprès du séquestre, les codes sources du logiciel accompagnés de l'ensemble des éléments de documentation définis en annexe et plus généralement de l'ensemble des informations nécessaires pour en permettre l'exploitation par tout homme de l'art.

Le dépôt des codes sources du logiciel devra être effectué par le fournisseur à la signature du contrat. Dans le cas où des évolutions ou modifications seraient apportées au logiciel par le fournisseur dans le cadre du contrat de maintenance qui le lie au client, ces dernières devront être déposées par le fournisseur auprès du séquestre, au plus tard deux jours calendaires suivant leur remise au client par le fournisseur ».

En troisième lieu, l'on s'attachera à définir les modalités de contrôle par le séquestre de la complétude et de la conformité des codes sources qui lui sont remis, par rapport au code objet utilisé par le client. Dans le même ordre d'idées, on ne manquera pas de prévoir un mécanisme d'information suffisant pour permettre au client de s'assurer auprès du séquestre que le fournisseur du logiciel remplit ses engagements, notamment en termes de remise des codes sources .

Il faudra, ensuite, en quatrième lieu, prévoir les différents « cas d'ouverture » dans lesquels le client pourra requérir l'accès aux codes sources auprès du tiers séquestre.

Page 7: Code Sources

En pratique, s'il est d'usage de prévoir que la remise des sources au client doive s'effectuer dans les hypothèses de « cessation d'activité » ou de « liquidation judiciaire » du fournisseur du logiciel, voire en cas « d'abstention totale du fournisseur d'exécuter ses obligations de maintenance » (le cas échéant à l'issue d'un délai de préavis raisonnable), on gagnera également à prévoir que la rupture du contrat de maintenance conclu entre le fournisseur et le client suite à une faute imputable au fournisseur puisse, elle aussi, entraîner la remise des sources au client.

On pourra sur ce point s'inspirer de la clause suivante :

« Le fournisseur autorise le client à accéder aux codes sources déposés auprès du séquestre, dans les cas suivants :

- cessation d'activité du fournisseur et/ou ouverture d'une procédure de liquidation judiciaire à son égard ; ou

- cessation par le fournisseur des prestations objet du contrat de maintenance en vigueur entre le fournisseur et le client, c'est-à-dire dans le cas où le fournisseur s'abstiendrait totalement d'exécuter de telles prestations pendant une période de plus de trente jours malgré une demande du client par lettre recommandée avec accusé de réception ; ou

- résiliation du contrat de maintenance en vigueur entre le fournisseur et le client pour faute du fournisseur ».

C'est sans doute sur le dernier point que les négociations entre le client et le fournisseur du logiciel seront les plus difficiles, le fournisseur ayant tout intérêt à limiter le plus possible les hypothèses d'accès du client aux codes sources du logiciel alors qu'il n'a pas définitivement cessé son activité, tandis que le client cherchera en priorité à se prémunir contre un fournisseur qui, sans pour autant s'abstenir totalement de maintenir le logiciel, s'exécuterait avec si peu de diligence qu'il finirait par mettre en péril l'activité du client.

On veillera en tout cas à prévoir des cas d'ouverture suffisamment objectifs pour éviter toute difficulté lorsqu'il s'agira d'établir la preuve de leur survenance. En effet, sauf à ce que les parties n'en décident autrement (hypothèse pour le moins théorique), le contrat de séquestre n'est pas une « garantie à première demande », il faudra donc pour le client démonter au séquestre que sa demande d'accès aux sources est fondée.

Il convient ici de noter que certains séquestres ont pour habitude de prévoir un mécanisme d'arbitrage aux termes duquel ils apprécient selon leurs propres critères l'existence ou non d'une « défaillance » du fournisseur susceptible de donner lieu à la remise des codes sources au client. S'il est normal que le séquestre puisse avoir à s'assurer que les motifs invoqués par le client sont fondés, il nous semble cependant préférable d'éviter de recourir à un tel mécanisme d'arbitrage qui, au-delà d'une simple vérification de la réalisation des cas d'ouverture prévus entre les parties, fait peser un aléa sur la définition même des cas d'ouverture et pourra en outre entraîner le client dans une procédure arbitrale longue et complexe.

Au-delà des cas d'ouverture et des modalités de remise des sources par le séquestre, il ne faudra pas non plus, en dernier lieu, oublier de prévoir une clause de propriété intellectuelle précisant la nature des droits concédés au client sur les codes sources du logiciel en cas de remise par le séquestre.

En effet, l'accès aux sources auprès d'un séquestre et la question de la titularité des droits de propriété intellectuelle doivent être clairement dissociés31 : le logiciel demeure dans tous les cas la propriété du fournisseur et la remise des sources n'entraîne de facto aucun transfert de droits de propriété intellectuelle au profit du client. Sur ce point et bien que la liberté contractuelle permette d'accorder au client les droits les plus étendus sur le logiciel, il semblerait cependant logique que le droit d'accès aux sources ne s'accompagne pour le client que des seuls droits nécessaires à l'exécution par ce dernier, ou par un tiers pour le compte de ce dernier, des obligations que le fournisseur se devait d'exécuter au profit du client dans le cadre du contrat de licence ou de maintenance.

Quelle que soit l'étendue de ces droits, on veillera à ce qu'ils soient concédés pour une durée et un territoire identiques à ceux pour lesquels le client dispose du droit d'utilisation du code objet du logiciel.

Page 8: Code Sources

Ce bref panorama des points fondamentaux du contrat de séquestre est bien sûr loin de refléter l'exhaustivité des clauses à prévoir dans un tel contrat. Le contrat de séquestre est en effet un contrat complexe qui nécessitera que l'on s'appesantisse quelque peu sur sa rédaction et que l'on ait quelque expérience des relations contractuelles à trois parties.

C'est pourquoi, dans l'urgence de la vie des affaires, il pourrait parfois paraître plus pratique au client, surtout lorsqu'il est relativement profane en la matière, d'adhérer sans conditions à un programme de séquestre unilatéralement mis en place et proposé par le fournisseur du logiciel. Nous verrons cependant que cette option reste à envisager avec vigilance.

2. L'adhésion du client à un programme de séquestre préétabli

La pratique du programme de séquestre est relativement simple : un éditeur professionnel qui est régulièrement amené à conclure des conventions de séquestre avec plusieurs clients sur un même logiciel met en place unilatéralement une convention de séquestre dont l'ensemble de ses clients pourra bénéficier par le jeu d'un mécanisme de stipulation pour autrui.

Ainsi, dans le cadre de la négociation d'un contrat de licence, le praticien se verra-t-il souvent confronté à un éditeur qui, au moment d'aborder l'épineuse question de l'accès aux sources , se contentera d'indiquer que les sources de son logiciel sont déposées auprès de tel ou tel séquestre, souvent de nationalité étrangère et parfaitement inconnu du client.

Si l'existence d'un dépôt du logiciel est en soi de nature à rassurer, il serait bien imprudent de se satisfaire de cette simple affirmation.

Il faudra bien sûr tout d'abord demander la production de la convention conclue entre le fournisseur et son séquestre, ainsi que, le cas échéant, une attestation du séquestre pour s'assurer de sa validité.

Il faudra cependant surtout se livrer à une étude très approfondie des stipulations de cette convention pour s'assurer en priorité des points suivants :

- que les droits conférés au client par une convention à laquelle il n'est pas partie32 sont bien opposables au séquestre (présence d'une clause explicite de stipulation pour autrui au bénéfice de tout utilisateur du logiciel qui pourrait justifier de la conclusion d'un contrat de licence en bonne et due forme sur le logiciel), le cas échéant par la production d'une attestation émanant du séquestre. Sur ce point, il convient de noter que, souvent, le bénéfice du programme de séquestre sera subordonné à l'accomplissement par le client de formalités diverses auprès du séquestre, telles que notamment l'envoi à ce dernier d'un formulaire d'enregistrement. Même s'il n'est pas toujours précisé quand ces formalités devront être accomplies, il vaudra mieux s'en acquitter scrupuleusement pour ne pas risquer de se voir refuser l'accès aux sources , lorsque la nécessité s'en présentera. À noter que dans le cas d'un dépôt effectué par le fournisseur à l'APP, le bénéfice du séquestre est accordé par principe à tout utilisateur ayant régulièrement acquis un droit d'usage sur ce dernier, sous réserve cependant que le fournisseur du logiciel lui ait expressément accordé ce bénéfice par écrit, par exemple par une clause du contrat de licence ;

- que les modalités de dépôt des sources s'accompagnent bien d'une vérification par le séquestre de leur conformité au code objet du logiciel et que la convention a bien vocation à permettre le dépôt des mises à jour et évolutions du logiciel. À noter que sur ce point, même si l'on souscrit sans conditions au programme de séquestre, on devra impérativement prévoir dans la convention entre le client et le fournisseur du logiciel, l'obligation pour ce dernier de procéder promptement auprès du séquestre au dépôt de chaque évolution du logiciel fournie au client ;

- que la convention offre au client un mécanisme quelconque lui permettant de s'assurer que le fournisseur dépose régulièrement les évolutions du logiciel auprès du séquestre, conformément à ses engagements envers le client. Il faudra sur ce point être vigilant, car lorsque cette modalité sera prévue, elle sera le plus souvent soumise à un abonnement du client auprès du séquestre, abonnement presque toujours payant ;

- que les cas d'accès aux sources prévus à la convention sont acceptables au regard des risques contre lesquels le client souhaite se prémunir. En effet, si, dans quelques rares hypothèses, la convention de séquestre laisse place aux hypothèses prévues au contrat de licence conclu entre le client et le fournisseur33, en pratique la plupart des programmes de

Page 9: Code Sources

séquestre se limitent à prévoir un accès aux sources dans le seul cas de liquidation judiciaire du fournisseur du programme, l'hypothèse d'une défaillance dans le cadre de l'exécution de ses obligations de maintenance n'étant pas couverte ;

- que la convention de séquestre n'impose pas de frais pour le client. S'il est rare mais possible (notamment dans certains « Escrow Programs »34 anglo-saxons) que le bénéfice même du séquestre soit subordonné à un abonnement du client, il est en revanche très fréquent que la remise des codes sources au client, lorsque les cas d'ouverture sont remplis, soit subordonnée au paiement de frais de dossier non négligeables, voire quelquefois littéralement exorbitants ;

- que la convention de séquestre est soumise au droit et à la juridiction du pays du client, ce qui ne sera généralement pas le cas en présence d'un séquestre de nationalité étrangère.

Si le séquestre choisi par le fournisseur est l'APP, il faudra par ailleurs redoubler de vigilance sur deux points particuliers.

Tout d'abord, on veillera tout particulièrement à s'enquérir du type de dépôt effectué auprès de l'APP. Cette dernière propose en effet le choix entre plusieurs modalités de dépôt35 : du simple « référencement », qui n'a pour objet que de permettre à l'éditeur de justifier de l'antériorité de son programme mais qui n'offre aucun droit d'accès aux sources pour les utilisateurs, au « dépôt contrôlé », seule modalité dans laquelle l'APP procède à la vérification de la conformité des sources déposées par rapport au code objet du logiciel.

Ensuite, il faudra garder à l'esprit que l'article 6 du règlement général de l'APP subordonne l'accès du client aux codes sources à une procédure d'arbitrage destinée à apprécier l'existence d'une « défaillance du créateur du programme ».

Si le client et le fournisseur ne souhaitent pas s'en remettre à cette procédure, ils pourront l'exclure par une stipulation expresse du contrat de licence qui pourra, par exemple, prendre la forme suivante :

« Les parties conviennent expressément de déroger aux dispositions de l'article 6 du règlement général de l'Agence pour la protection des programmes (APP). À ce titre, il est expressément convenu que le client pourra accéder aux codes sources du logiciel : (i) sans avoir recours aux instances de conciliation et/ou d'arbitrage de l'APP et (ii) dans les cas d'ouverture prévus au présent article, lesquels constituent expressément une défaillance du créateur du programme" au sens du règlement général de l'APP ».

Une telle stipulation devra cependant être portée à la connaissance de l'APP.

Dans tous les cas, on gagnera36 à faire mention de l'existence du programme de séquestre dans la convention entre le client et le fournisseur, en y annexant, le cas échéant, le contrat de séquestre conclu entre le fournisseur et le tiers séquestre ainsi que les éventuelles attestations obtenues du séquestre pour s'assurer de son opposabilité au séquestre par le client.

Par ailleurs, et pour les raisons invoquées au c. 1 de notre étude, l'on devra également veiller à préciser, dans la convention conclue entre le client et le fournisseur du logiciel, l'étendue des droits conférés au client sur le logiciel en cas de remise des codes sources par le séquestre.

Conclusion

La revendication du client portant sur l'accès aux codes sources , d'une part, et le souci du fournisseur du logiciel de conserver la maîtrise d'un produit dont il n'a pas cédé ou concédé les droits de modification et de correction, d'autre part, correspondent à des intérêts qui semblent contradictoires.

Cependant, la solution contractuelle est un moyen de les concilier, à la condition de veiller à déterminer précisément les conditions d'accès aux codes sources et de faire preuve de vigilance par rapport aux usages de la pratique qui ne vont pas toujours dans le sens de la protection des intérêts du client.

Encore faut-il toutefois que le fournisseur du logiciel accepte d'organiser contractuellement la communication des codes sources .

Page 10: Code Sources

Or, certains fournisseurs du marché disent ne pas avoir confiance dans les contrats de séquestre et refusent systématiquement, sous prétexte de protection de leur savoir-faire, tout droit d'accès au client sur les sources de leurs produits. Cette attitude critiquable a pour effet d'enserrer le client dans une dépendance technologique d'autant plus totale que le recours à leurs produits pourra parfois se révéler incontournable dans certains secteurs d'activité.

À l'image du droit de la concurrence qui sanctionne l'« abus de dépendance économique », on pourrait envisager que le législateur puisse, un jour, venir sanctionner l'« abus de dépendance technologique » d'un fournisseur qui refuse systématiquement de séquestrer ses sources .

Certains auteurs ont d'ailleurs déjà souligné à quel point les codes sources sont solubles dans la théorie des « facilités essentielles », du fait du monopole, et par conséquent de la position dominante qu'ils octroient au titulaire des droits sur la maintenance37.

Arnauld VAN EECKHOUT

1. Techniquement, les logiciels informatiques ne sont jamais exempts d'erreurs. On désigne par « maintenance corrective » l'ensemble des tâches consistant à corriger ces erreurs.

2. E. Montero, Les contrats de l'informatique et de l'Internet, Larcier, 2005.

3. Il s'agira le plus souvent de l'auteur du logiciel, d'un éditeur ou d'un prestataire informatique qui aura procédé au développement du logiciel et en aura conservé les droits de correction, de modification et d'adaptation.

4. Le binaire se présente sous la forme d'une suite de 0 et de 1 que les processeurs des ordinateurs sont capables d'interpréter.

5. V. pour plus de détails la définition des codes sources donnée par MM. les Professeurs H. Croze et F. Saunier, « Logiciels : retour aux sources », JCP G 1996, I, no 3909.

6. Il existe un très grand nombre de langages informatiques bien connus des programmeurs, tels que par exemple le BASIC, le C, ou encore le C++.

7. C. propr. intell., art. L. 122-6 : « Sous réserve des dispositions de l'article L. 122-6-1, le droit d'exploitation appartenant à l'auteur d'un logiciel comprend le droit d'effectuer et d'autoriser : 1o La reproduction permanente ou provisoire d'un logiciel en tout ou partie par tout moyen et sous toute forme. Dans la mesure où le chargement, l'affichage, l'exécution, la transmission ou le stockage de ce logiciel nécessitent une reproduction, ces actes ne sont possibles qu'avec l'autorisation de l'auteur ;2o La traduction, l'adaptation, l'arrangement ou toute autre modification d'un logiciel et la reproduction du logiciel en résultant ;3o La mise sur le marché à titre onéreux ou gratuit, y compris la location, du ou des exemplaires d'un logiciel par tout procédé. Toutefois, la première vente d'un exemplaire d'un logiciel dans le territoire d'un État membre de la Communauté européenne ou d'un État partie à l'accord sur l'Espace économique européen par l'auteur ou avec son consentement épuise le droit de mise sur le marché de cet exemplaire dans tous les États membres à l'exception du droit d'autoriser la location ultérieure d'un exemplaire ».

8. C. Le Stanc et S. Carré, Juris-Classeur Propriété littéraire et artistique, Fasc. 1250.

9. A. Lucas, J. Devèze et J. Frayssinet, « Droit de l'informatique et de l'internet », PUF, coll. « Thémis Droit privé », no 756.

10. H. Croze et F. Saunier, « Logiciels, retour aux sources », préc.

11. X. Linant de Bellefonds, « Le droit de décompilation du logiciel : une aubaine pour les cloneurs ? », JCP G 1998, I, 118.

12. H. Bitan, Contrats et litiges en informatique, la délivrance du logiciel, PUAM, 1996.

Page 11: Code Sources

13. Le compilateur est lui-même un logiciel qui permet de traduire le langage du code source au profit d'une machine spécifique.

14. M.-A. Ledieu, « Logiciel spécifique, correction des erreurs et code source : les tribulations d'un Français au paradis offshore du développement de logiciel », Comm. com. électr., juill. 2004, no 7, Étude 21.

15. E. Montero, Les contrats de l'informatique et de l'internet, op. cit.

16. Il s'agit d'un logiciel qui n'a pas été réalisé spécifiquement pour les besoins d'un client.

17. TGI Melun, 2 mars 1988, DIT 1988, no 4.

18. Il s'agit d'un logiciel spécifiquement réalisé pour les besoins du client dans le cadre d'un contrat d'entreprise.

19. F. Dupuis-Toubol, « La mise sous séquestre des codes de logiciels », Expertises 1991, livr. 142, p. 292 ; J. Huet et H. Maisl, Droit de l'informatique et des télécommunications, Litec, 1989, p. 405 et s.

20. CA Bordeaux, 24 sept. 1984, no 3286/84.

21. TGI Paris, ord. réf., 10 avr. 2002, LPA 28 janv. 2003, p. 10, note Fernandez.

22. Cass. com., 10 mai 2000, pourvoi no 91-17.277.

23. H. Croze et F. Saunier, « Logiciels : retour aux sources », préc.

24. Cette exigence résulte de l'article L. 131-3 du Code de la propriété intellectuelle.

25. H. Croze et F. Saunier, « Logiciels : retour aux sources », préc.

26. C'est là une position particulièrement discutable qui est parfois soutenue par certains éditeurs de logiciels pour refuser la mise en place d'un séquestre avec un tiers, fût-il assermenté et tenu au secret professionnel, comme un notaire par exemple.

27. C'est désormais une jurisprudence constante. Une telle obligation pourra cependant permettre d'obtenir la condamnation sous astreinte de l'éditeur à remettre les sources .

28. Ce mécanisme est souvent désigné par le terme « séquestre » ou par sa traduction anglaise « escrow ».

29. http://app.legalis.net

30. http://www.logitas.fr

31. CA Nîmes, 29 nov. 1989, DIIJ, no 7/1991, p. 39 : « La remise des codes sources n'est pas incompatible avec la conservation de la propriété intellectuelle de l'oeuvre ».

32. Cela résulte des dispositions de l'article 1165 du Code civil selon lesquelles les conventions n'ont pas d'effet à l'égard des tiers.

33. C'est le cas notamment des conditions générales de la société Logitas SA.

34. Traduction anglaise de l'expression « programme de séquestre ».

35. Pour plus d'informations, se reporter au site Internet de l'APP : http://app.legalis.net

36. Comme exposé plus haut dans notre étude, c'est d'ailleurs indispensable pour bénéficier du séquestre effectué auprès de l'APP.

Page 12: Code Sources

37. R. Hardouin, « La maintenance de logiciel à l'épreuve de la théorie des facilités essentielles », 24 févr. 2005, www.juriscom.net.

RDCO2004-3-047Revue des Contrats, 01 juillet 2004 n° 3, P. 817 - Tous droits réservés

Licence de logiciel : son régime juridique à l'épreuve de la pratique

Les logiciels ont pris une place primordiale dans la vie et le fonctionnement des entreprises. Ils sont indispensables au traitement de l'information1, soit sous des formes très simples : logiciels de traitement de texte ou tableur, soit de manière plus sophistiquée : logiciels de comptabilité, systèmes permettant la gestion de centres d'appels, logiciels de conception (CAO) de dessin (DAO) ou de fabrication (FAO) assistée par ordinateur, systèmes de surveillance, logiciels antivirus...

Les investissements des entreprises dans la conception puis dans la pérennisation de leurs systèmes d'information représentent plusieurs dizaines de millions d'euros. L'économie de l'entreprise dépend en grande partie de son système d'information et notamment des logiciels qu'elle utilise pour les besoins de son activité. Il en découle une situation de dépendance des entreprises à l'égard de ces logiciels et, au-delà, à l'égard des concepteurs ou éditeurs de ces derniers.

Parallèlement, les investissements des concepteurs et éditeurs dans la conception des logiciels sont substantiels. À titre illustratif, l'industrie du logiciel représentait un chiffre d'affaires mondial de 570 milliards d'euros2 en 2003 et en France un chiffre d'affaires d'environ 21 milliards d'euros3 en 2002.

Le rapport contractuel entre l'éditeur et l'utilisateur du logiciel est donc particulièrement important pour protéger les investissements de chacun. Le contrat entre l'éditeur, qui est le seul titulaire du droit de propriété, et le client peut prendre différentes formes. Il s'agit soit d'une cession, soit d'une licence d'utilisation, c'est à dire d'un droit d'usage du logiciel. La doctrine reconnaît que la cession s'apparente traditionnellement au régime de la vente, de même que la licence à celui de la location.

L'assimilation de la licence de logiciel au régime général de la location de choses ne s'est pas faite aisément et résulte d'une longue construction tant jurisprudentielle que doctrinale. Cette assimilation entre le contrat de licence et le louage de chose date d'une jurisprudence ancienne appliquée aux brevets4. Mutatis mutandis, ce raisonnement a été appliqué aux licences de logiciels, protégés par un autre droit de propriété intellectuelle qu'est le droit d'auteur.

Néanmoins, au-delà de ces qualifications juridiques, il faut constater qu'en pratique, les contrats de licence de logiciels ou progiciels correspondent davantage à des contrats sui generis qu'à de classiques contrats de louage de choses.

Cette dérive résulte d'une part, de l'intérêt économique des éditeurs, qui tendent à préciser voire à limiter autant que possible les droits des utilisateurs des logiciels, d'autre part, de la transposition de concepts de «common law » auxquels se réfèrent les éditeurs en majorité anglo-saxons ou américains, enfin, de la réglementation spécifique applicable aux logiciels amenant une rédaction précise des clauses de propriété intellectuelle.

Définies par les éditeurs, les licences de logiciels ne correspondent pas toujours aux attentes et aux besoins des entreprises clientes, d'autant plus que ces contrats sont très souvent des contrats d'adhésion, peu négociables et peu négociés.

Ainsi, cette dérive se constate lors de la phase précontractuelle au cours de laquelle l'obligation de conseil voit sa portée affectée par le recours aux licences tests (I), lors de l'exécution du contrat, par la limitation des droits de l'utilisateur du logiciel (II) et la limitation des garanties données par l'éditeur à l'utilisateur (III).

I - Atténuation de l'obligation de conseil

Page 13: Code Sources

Avant de procéder à la conclusion d'un contrat de licence de logiciel, le client potentiel doit déterminer si ce programme informatique correspond bien, en terme de fonctionnalités et de performances, à ses besoins ou à ses contraintes, notamment pour l'intégration dans son système informatique. Seul le concepteur du programme (éditeur) ou son représentant (distributeur ou intégrateur) est à même d'apporter ce conseil.

A. - L'obligation de conseil de l'éditeur de logiciel

La jurisprudence a depuis longtemps admis que le vendeur de matériel informatique doit informer son client sur les capacités du logiciel d'exploitation et/ou du matériel vendu et de son adéquation avec les besoins du client.

L'obligation de conseil5 contient elle-même plusieurs obligations : obligation de s'informer des besoins du client6, de lui fournir tout renseignement utile concernant le logiciel ou le matériel en cause , de mise en garde7, notamment concernant les limites ou les contraintes, des caractéristiques techniques du logiciel, de proposer la solution la plus adéquate compte tenu des besoins définis, voire même de recommander de modifier les structures de l'entreprise ou de former son personnel.

Cette obligation de conseil en matière informatique, implicite en droit français, n'a pas à être inscrite dans le contrat.

Quant à la teneur de cette obligation, la doctrine hésite entre l'obligation de moyen et l'obligation de résultat. Il semblerait que, sur le principe, le prestataire soit tenu d'une obligation de résultat (obligation de fournir ce conseil) mais qu'il ne soit tenu que d'une obligation de moyens quant au contenu de ce conseil, le client restant in fine libre de ses choix8.

L'obligation imposée à l'éditeur est une obligation lourde de conséquences. Le non respect de cette obligation d'information « préalable » est très souvent sanctionné sur la base de la responsabilité contractuelle9. Cette solution peut être surprenante dans la mesure où cette absence d'information a eu lieu avant la conclusion du contrat et ne devrait donc logiquement pas être sanctionnée sur ce terrain. La sanction consistera soit en l'octroi de dommages et intérêts10, soit en l'annulation du contrat en raison de « l'erreur commise par l'acquéreur incompétent en la matière »11.

La contrepartie d'une telle obligation est l'obligation de collaboration imposée par la jurisprudence au client12. La jurisprudence a notamment tendance à donner raison à l'éditeur en cas d'insuffisances de précisions du cahier des charges. Le problème réside essentiellement dans une expression claire, concise et précise des attentes du client.

Dans un contrat de licence de logiciel, il conviendra lors de la rédaction d'apporter un soin particulier tant à l'obligation de conseil du professionnel qu'à celle de collaboration du client, par exemple :

« L'éditeur, après avoir eu accès à toutes les informations requises, a reconnu avoir parfaitement analysé les besoins de XXX, et s'est déclaré en mesure d'y répondre en ce qui concerne, tant le respect des délais, que les niveaux de qualité, de performance et de fiabilité recherchés par XXX ».

A contrario, la compétence du client en matière informatique allégera, à hauteur de cette compétence, l'obligation de conseil de l'éditeur : l'utilisateur informatisé depuis longtemps ne peut être assimilé à un profane13. Cependant, la jurisprudence retient à bon droit que cela ne dispense pas l'éditeur ou prestataire de son obligation de conseil « dès lors que les informaticiens de (...) ne disposaient pas de toutes les compétences nécessaires, s'agissant de l'installation de logiciels spécifiques »14.

Enfin, l'obligation de conseil et d'information de l'éditeur sera d'autant plus atténuée que le client connaissait le logiciel notamment s'il a eu la possibilité de tester celui-ci. De nombreux éditeurs de logiciels proposent ou imposent à leurs clients potentiels une licence test aux fins de leur permettre de vérifier l'adéquation du logiciel à leurs propres besoins.

B. - Le contrat de licence test

Page 14: Code Sources

La licence test15 correspond à une période d'essai des logiciels. Les stipulations de ce contrat prévoient un droit d'usage la plupart du temps gratuit, limité dans sa durée (quelques mois maximum) et limité quant aux droits de l'utilisateur (quelques testeurs sur un nombre de postes déterminés et identifiés).

Les obligations du testeur sont également limitées : restitution du logiciel et de ses supports éventuels à l'éditeur et, parfois, obligation de fournir à l'éditeur un rapport sur le déroulement et la conclusion des tests.

Le contrat de licence test gratuit peut être assimilé à un prêt à usage ou commodat16. Il en présente certaines caractéristiques : la licence test est consentie pour un usage déterminé et comporte une obligation de restitution comme dans le cadre du commodat.

Pour le futur client, la licence test lui permet d'apprécier le fonctionnement du logiciel directement au sein de son système informatique.

En revanche, ce contrat permet à l'éditeur d'atténuer son obligation de conseil, voire d'en transférer la charge à son client à qui il incombe désormais de vérifier l'adéquation du logiciel à ses besoins.

Par ailleurs, lors de cette phase, le contrat de licence test prévoit très souvent que la licence est concédée sur le logiciel en l'état et que l'éditeur ne donne aucune garantie au licencié. Il ne pourra donc encourir aucune responsabilité liée à l'utilisation faite par le licencié du logiciel testé. Après conclusion de la licence, l'éditeur pourrait tenter de se dégager de son obligation d'information et de conseil et donc de se déresponsabiliser en arguant du fait que le client a eu le temps et le loisir de prendre connaissance du logiciel et de son fonctionnement au sein de son système d'information.

II - Les limitations des droits de l'utilisateur

Les stipulations du contrat de licence en limitant les droits d'usage du client prennent en compte de manière imparfaite les différentes situations d'utilisation du logiciel auxquelles le client est confronté (A). Par ailleurs, l'éditeur s'approprie dans certains contrats de licence des droits de propriété intellectuelle sur les améliorations que la loi réserve à l'utilisateur (B).

A. - Des droits définis et limités

D'un point de vue économique, l'éditeur qui a investi dans le développement d'un progiciel le rentabilise par le nombre de licences concédés et donc de redevances encaissées. L'éditeur va définir les droits concédés, le périmètre d'utilisation, le nombre de personnes possédant le droit d'usage, et les restrictions à l'utilisation de ce droit.

La plupart des contrats de licence qualifient le droit d'usage de droit personnel intuitu personae et imposent à leurs clients des clauses relativement restrictives, par exemple :

« Except in accordance with the terms of this Licence, Licencee agrees not to sell, rent, lease, licence, sublicence, display, modify, time share, outsource or otherwise transfer the Product to, or permit the use of this Product by any third party ».

L'éditeur essaye de renforcer au maximum cette obligation en restreignant l'utilisation de son logiciel au seul client et à personne d'autre. Néanmoins, la rigidité de cette rédaction se révèle inadaptée à la pratique de l'externalisation. Aujourd'hui, les entreprises ont couramment recours à des prestataires de services à tous les niveaux y compris pour l'exploitation des systèmes informatiques (infogérance). Mais ces prestataires exercent leur fonction au sein même de l'entreprise en agissant au nom et pour le compte de cette dernière. Or, les licences des logiciels « acquis » auprès des éditeurs limitent le droit d'utilisation du client en général aux seuls personnels du client. Sans modification du contrat, l'utilisation par une société tierce resterait interdite. Avant toute décision d'infogérance, le client est donc en situation de dépendance à l'égard de son éditeur auprès duquel il doit obtenir un accord exprès lui permettant de faire utiliser les logiciels concernés par un tiers. De la même manière, la décision de recourir à la tierce maintenance pourrait faire face aux mêmes écueils.

Le rapprochement avec le contrat de bail conduirait en fait à analyser cette interdiction en une restriction d'utilisation des locaux par tout tiers non autorisé. Certes, le régime de la location permet d'interdire la sous location, et par analogie, le donneur de licence peut interdire la sous

Page 15: Code Sources

licence17. Or le fait de confier à un tiers l'utilisation du logiciel pour son compte (infogérance) ne doit pas s'analyser en une sous licence, car cette utilisation ne se fait pas au bénéfice du tiers mais, au contraire, au bénéfice du licencié.

B. - Un régime d'attribution des améliorations surprenant

Certains contrats de licences de logiciels, au détour d'un article rappelant les droits de l'éditeur sur le logiciel concédé et les obligations du licencié (ne pas reproduire, ne pas décompiler etc.) prévoient une cession expresse des améliorations faites par le licencié sur le logiciel au profit de l'éditeur.

Le Code de la propriété intellectuelle est pourtant très clair : le logiciel incorporant un autre logiciel est une oeuvre composite18. Celle-ci est la propriété de son créateur sous réserve des droits de l'auteur de l'oeuvre première (ce qui impliquera que l'auteur de l'oeuvre seconde doive obtenir l'accord et, le cas échéant, rémunérer l'auteur de l'oeuvre première).

Cette dévolution automatique à l'éditeur du résultat des développements informatiques réalisés par le client à ses propres frais pourrait être frappée de nullité pour absence de cause en l'absence de rémunération du licencié.

La bonne pratique conduit donc à ne pas accepter de telles stipulations.

III - Les clauses de limitation de garantie et de responsabilité

S'agissant de garanties et de responsabilité, un des traits communs des licences est l'exclusion quasi totale de responsabilité de l'éditeur du logiciel aussi bien en ce qui concerne le fonctionnement que le contenu du logiciel (A), lequel fonctionnement dépend alors de la conclusion d'un contrat de maintenance (B).

A. - Les exclusions de garanties

Que le contrat soit rédigé en français ou en anglais, les stipulations relatives aux garanties qu'offre l'éditeur sur le logiciel ou plutôt à son absence de garantie sont similaires - voire identiques - d'une licence à l'autre.

1) Limitations dans le contenu

Ces clauses visent d'une part à limiter le contenu de la garantie de conformité19 ou de bon fonctionnement à une conformité à la documentation, d'autre part à exclure ou limiter toute garantie de performance du logiciel ou de résultat attendue de ce logiciel20.

Le contenu et la forme de ces clauses limitatives de garantie de conformité sont directement inspirés de fondements juridiques nord-américains. En particulier, les garanties « Implied Warranty » et de « Fitness for a Particular Purpose » sont des garanties prévues par le « Uniform Commercial Code (U.C.C.) » américain21.

Ces deux obligations, expressément prévues aux articles 2-314 et 2-315 du U.C.C., sont normalement appliquées de façon implicite. Il est cependant juridiquement possible, entre professionnels, de les exclure des contrats, notamment des licences de logiciel s'il est fait expressément mention des termes « merchantability » et de « fitness for purpose »22, et si l'inscription d'une telle exclusion est mise en relief par rapport au format normal du texte contractuel (« conspicuous »)23.

Pour les contrats qui restent soumis au droit américain, le juge américain peut atténuer la portée de ces clauses limitatives de responsabilité lorsque le client n'aura pas eu l'opportunité de négocier le contrat24. En effet, il est admis par les tribunaux américains que lorsque la licence porte sur un progiciel dans le cadre d'un contrat d'adhésion, l'utilisateur peut demander au tribunal de passer outre l'exclusion par l'éditeur de sa responsabilité en application de la « doctrine of unconscionability ». Ce qui permet à l'acheteur de faire appliquer la « warranty of merchantability » et donc de surmonter la limitation contractuelle.

Pour les contrats de licences qui restent soumis au droit français, il est possible d'atténuer leur portée en faisant le rapprochement avec le régime de la location.

Page 16: Code Sources

L'application des clauses limitatives de responsabilité en droit français est partiellement contradictoire avec le régime de la location parce qu'elles remettent en cause la garantie du bailleur d'assurer la conformité de la destination de la chose louée. En effet, le loueur doit permettre au locataire de faire usage de la chose. Cette obligation découle doublement de l'obligation de délivrance25 et de l'obligation « d'entretenir la chose en état de servir à l'usage auquel elle a été louée »26étant entendu que seule cette dernière obligation peut faire l'objet de dérogations contractuelles.

2) Limitation dans le temps

La garantie de bon fonctionnement du logiciel par l'éditeur est très souvent limitée à 90 jours.

Le parallèle avec le régime de la location imposerait normalement à l'éditeur d'assurer le bon fonctionnement de son logiciel pendant toute la durée du contrat de licence27. Néanmoins, le caractère supplétif de ces dispositions permet au bailleur-éditeur de se défausser de cette obligation sur son locataire-licencié.

3) Limitation dans l'indemnisation

Les dommages et intérêts qu'accepte de payer l'éditeur pour un logiciel défectueux sont plafonnés au prix payé pour le logiciel28. Par exemple :

« Si le logiciel ne fonctionne pas correctement, l'entière responsabilité de XXX et vos seuls recours se limiteront au choix de XXX au remplacement du Logiciel ou au remboursement de la redevance que vous avez versée pour obtenir la licence du Logiciel ».

Par ailleurs, la plupart des contrats de licence excluent la responsabilité des éditeurs en cas de dommages immatériels (pertes d'exploitation, pertes de données,...).

Ainsi, certaines clauses stipulent par exemple que 29 :

« LIMITATION DE RESPONSABILITÉ. EN AUCUN CAS XXX OU SES FOURNISSEURS NE SERONT RESPONSABLES ENVERS VOUS POUR TOUS DOMMAGES, RÉCLAMATIONS OU QUELQUES COÛTS QUE CE SOIT OU POUR TOUS DOMMAGES DIRECTS OU INDIRECTS, OU POUR TOUT MANQUE À GAGNER, PERTES D'EXPLOITATION, PERTES DE BÉNÉFICES, ET CE MÊME SI UN REPRÉSENTANT DE XXX A ÉTÉ INFORMÉ DE LA POSSIBILITÉ DE TELS DOMMAGES, PERTES, RÉCLAMATIONS OU COÛTS ».

Or, les dommages ainsi alloués par l'éditeur peuvent dans certains cas être sans aucun rapport avec le préjudice éventuellement subi par le client en cas d'interruption prolongée du système informatique. Beaucoup de logiciels aujourd'hui concourent à la réalisation du chiffre d'affaires de l'entreprise (exemple : logiciel gérant les flux de facturation d'un opérateur mobile).

II est possible de limiter l'efficacité de ces clauses sur le fondement de la jurisprudence Chronopost30. Le client pourra soutenir, devant les tribunaux, que l'obligation essentielle de l'éditeur est de lui concéder un droit d'usage sur un logiciel qui fonctionne conformément à l'usage auquel il est destiné. Toute anomalie affectant son fonctionnement prive l'utilisateur de cet usage, et le client pourra prétendre à une réparation non limitée au simple remplacement ou remboursement du logiciel.

Le client utilisateur du logiciel se trouve donc acquéreur d'un logiciel dont la garantie est très limitée dans le temps et dans ses effets. Néanmoins, pour répondre à cette situation de carence, les éditeurs « offrent » la possibilité de conclure des contrats de maintenance de logiciels permettant d'allonger la garantie limitée dans la licence.

B. - Le contrat de maintenance

Le client, titulaire d'un contrat de licence, ne reçoit qu'un droit limité d'utilisation du logiciel, n'a pas accès aux sources , n'a aucun droit de modifier, d'adapter le logiciel et de modifier les codes sources pour parer aux éventuels bogues.

Pour remédier à cette carence, l'éditeur « propose » à son client31 un contrat de maintenance accessoire au contrat de licence. Ce contrat de maintenance définit l'obligation d'entretien, les conditions d'intervention et de corrections en cas de bogues, mais également très souvent la

Page 17: Code Sources

mise à disposition des différentes versions et mises à jour. La pratique des éditeurs leur permet de s'affranchir de leurs obligations de correction des vices de conception en mettant à disposition des utilisateurs des mises à jour (assimilées à des nouvelles versions) intégrant les corrections des bogues.

Le client se retrouve donc dans la situation paradoxale dans laquelle son droit à garantie de bon fonctionnement du logiciel se trouve transformé en une obligation de paiement32 au titre d'un contrat de maintenance distinct.

Conscient des divergences d'intérêts des utilisateurs et des éditeurs, et notamment des dérives et carences illustrées ci-dessus, le CIGREF (association d'entreprises utilisatrices d'informatique) et le SYNTEC (chambre syndicale professionnelle des SSII et des éditeurs de logiciels), se sont engagés en mars 2003 à établir des règles pour clarifier leurs relations en ce qui concerne les principaux contrats informatiques : infogérance et tierce maintenance applicative, ingénierie et intégration de systèmes, progiciels et licences, études et conseil.

Ainsi, le 31 mars 2004 a été publiée une Charte commune contenant des recommandations relatives à toutes les prestations réalisées par un prestataire du SYNTEC informatique pour un client membre du CIGREF et, notamment, un certain nombre de règles de l'art en matière informatique, allant même jusqu'à de véritables engagements des parties, notamment sur la lisibilité des tarifs, le respect des droits sur les progiciels, les règles de transfert des droits d'usage, ou de comptage des logiciels.

Si elle n'établit pas totalement un équilibre entre éditeurs et clients, cette charte, a priori dépourvue de valeur juridique, devrait cependant fournir des arguments aux parties lors des négociations des licences de logiciels.

Franck DELAMER et Arnaud VAN EECKHOUT

1. Le logiciel est en effet défini comme étant « l'ensemble des programmes, procédés et règles, et éventuellement de la documentation, relatifs au fonctionnement d'un ensemble de traitement de l'information ». Arrêté du 22 décembre 1981 relatif à l'enrichissement du vocabulaire de la langue française. JONC 17 janv. 1982, p. 624.

2. Source : IDATE.

3. Source SYNTEC Informatique.

4. Concernant un contrat de licence de brevet :Tribunal de Commerce de la Seine le 20 octobre 1922 - Annales de la Propriété Industrielle - 1923 no 9.

5. Voir notamment, pour des exemples de jurisprudence constante en la matière, « M. Vivant, Chronique Droit de l'informatique », JCP éd. E 1995, no 18 , Cass. civ. 1re, 25 juin 1996, Revue Droit de l'informatique et des télécoms, 1997, no 3, p. 27.

6. Com., 5 janvier 1999, Expertise 1999, 269. Cass. com., 6 mai 2003.

7. CA Paris, 4 janvier 1980.

8. Cf. Ph. le Tourneau « Théorie et Pratique des Contrats Informatiques ». Dalloz p. 10. A contrario, T. Verbielst. Droit des Nouvelles Technologies « sauf clause contractuelle contraire, l'obligation d'information du prestataire informatique est une obligation de moyen et non de résultat ».

9. Cass. com., 12 novembre 1992. Droit Informatique et télécoms 1993 /2 page 46.

10. CA Nancy, 19 juin 2002, Jurisdata 2002-214204.

Page 18: Code Sources

11. La portée de cette sanction étant déterminée par la qualité du client (profane ou non), la portée du manquement (absence totale de conseil), ou le caractère déterminant du logiciel pour le client. Cass. com., 3 avril 2002, Jurisdata 2002-013872.

12. Il s'agit également d'une jurisprudence constante : obligation de coopération et de participation du client.

13. CA Paris, 25e ch B, 24 juin 1988, Sté C. Prop. C/Sté Kienzle Informatique, Jurisdata no 23947 p.13 , Cass. com., 6 oct. 1998, Rev. Lamy dr. Aff. 1998, no 10, no 637, obs. L. Costes.

14. Cass. com., 6 mai 2003, Sté Promatec c/ UGMR (société possédant en interne un service informatique).

15. Autrement dénommée « trial licence » ou « evaluation licence agreement ».

16. Article 1875 du Code civil.

17. Article 1717 du Code civil.

18. Article L. 113-2 du Code de la propriété intellectuelle « Est dite composite l'oeuvre nouvelle à laquelle est incorporée une oeuvre préexistante sans la collaboration de l'auteur de cette dernière ».

19. Pour un exemple en anglais : « Licensor warrants that, for a period of ninety days from original shipment, the product, when executing on compatible computers and operating systems designated by the Licensor, will perform in substantial accordance with designated product specifications, and that the documentation and Media are free from any physical defects. Licensor and its suppliers do not warrant that the product or documentation are without defect or error or that the operation of the product will be uninterrupted or that, except as otherwise expressly stated in the documentation, it will operate in combination with other software and hardware selected by Licensee (...). LICENSOR MAKES NO OTHER WARRANTY, CONDITION, REPRESENTATION, OR PROMISE IF IT NOT SET FORTH HEREIN. LICENSOR DISCLAIMS AND EXCLUDES ALL IMPLIED WARRANTIES OF MERCHANTABILITY, TITLE AND FITNESS FOR A PARTICULAR PURPOSE (...) ».

20. Par exemple : « De faibles variations de performances par rapport aux spécifications de la Documentation ne donnent pas lieu à un droit à garantie ».

21. Voir S. Lipovetski « Les clauses limitatives de responsabilités et de garantie dans les contrats informatiques. France/États-Unis. » Expertises mai 2000 p. 143.

22. « [...] To exclude or modify the implied warranty of merchantability or any part of it the language must mention merchantability and in case of a writing must be conspicuous, and to exclude or modify any implied warranty of fitness the exclusion must be by a writing and conspicuous. Language to exclude all implied warranties of fitness is sufficient if it states, for example, that « There are no warranties which extend beyond the description on the face hereof » ». Article 2-316 du U.C.C.

23. « LICENSOR MAKES NO OTHER WARRANTY, CONDITION, REPRESENTATION, OR PROMISE IF IT NOT SET FORTH HEREIN. LICENSOR DISCLAIMS AND EXCLUDES ALL IMPLIED WARRANTIES OF MERCHANTABILITY, TITLE AND FITNESS FOR A PARTICULAR PURPOSE ».

24. Mais les licences de logiciels sont très souvent des contrats d'adhésion.

25. Article 1719-1o du Code civil.

26. Article 1719-2o du Code civil.

27. Article 1719-2 du Code civil.

28. Par exemple : « LA RESPONSABILITE TOTALE DE XXX ET CELLE DE SES FOURNISSEURS DANS LE CADRE DE CE CONTRAT OU EN RAPPORT AVEC CE DERNIER EST LIMITEE A LA SOMME VERSEE POUR LE LOGICIEL S'IL Y A LIEU ».

Page 19: Code Sources

29. Pour un exemple en anglais « In no event shall licensor be liable for any consequential, special, incidental, punitive or indirect damages of any kind arising out of the use of this product or lost profits or business, loss of data or costs of recreating lost data even if licensor has been advised of the possibility of such damages ».

30. CA Paris, 25e ch., sect. B, 22 juin 2001, Sté Unisys France c/ Sté Cogim et autres, Juris-data no 2001-152084. Voir également Cass. com., 22 octobre 1996, Chronopost, JCP 1997, II, 22881 note D. Cohen.

31. Additional support and maintenance may be available for an additional charge , contact Licensor or Licensor reseller for details ».

32. Ce raisonnement peut être corroboré par le fait que, très souvent, le prix de la maintenance est fixé en pourcentage du prix du contrat de licence, ce qui démontre l'interdépendance entre ces deux contrats.