Vous êtes sur la page 1sur 19

RDCO2007-4-046

Revue 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
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.

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

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
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.

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.

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.

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
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 .

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.

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.

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-047
Revue 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

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

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
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.

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
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.

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 ».

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.

Vous aimerez peut-être aussi