L'an 2000 n'avait pas été prévu par les informaticiens, les années n'étant exprimées que par les unités et les dizaines, dans la plupart des logiciels.

Cette lacune doit être réparée au risque de voir les systèmes d'information bloqués ou générant des résultats erronés à compter du 1er janvier 2000. Les solutions existent. Une question demeure : qui doit prendre en charge le coût des adaptations des logiciels et progiciels pour qu'ils puissent fonctionner après le 1er janvier 2000 ?

La problématique juridique présente des analogies avec le passage à la numérotation téléphonique à 10 chiffres ou avec l'abandon des monnaies nationales et l'adoption de l'Euro.

Toutefois, la spécificité de chacun de ces événements peut appeler des réponses juridiques sensiblement différentes, principalement du fait du caractère inéluctable ou non de l'événement.

L'utilisateur peut se prévaloir de divers fondements juridiques pour essayer de faire prendre en charge par le fournisseur les évolutions associées au passage à l'an 2000 et à la monnaie unique ; certains fondements étant intrinsèques à la relation contractuelle, d'autres étant périphériques à cette relation.

Fondements intrinsèques à la relation contractuelle

Les fondements existent non seulement au titre de l'obligation de garantie, lors de l'utilisation du logiciel, mais encore au titre de la maintenance du logiciel.

Obligations de garantie

Sans négliger les hésitations qui peuvent encore exister pour appliquer le régime de la vente à une licence d'utilisation d'un exemplaire de logiciel standard, et en dépit d'une absence de jurisprudence clairement établie en ce sens, mais avec néanmoins une référence expresse à la vente dans l'article L. 122-6 3ème du code de la propriété intellectuelle (1), l'étude des garanties sur le logiciel ne peut faire l'économie d'une analyse en droit de la vente. Si l'expression "vente" n'a été choisie ni par hasard ni par mégarde par le Parlement, traducteur de la directive du 14 mai 1991 sur la protection des programmes d'ordinateur, l'analyse en contrat de vente doit néanmoins être limitée à certains types de commercialisation portant sur les logiciels standard et au cas de la partie logicielle des systèmes d'exploitation incluse dans les matériels ; les contrats portant sur la réalisation des logiciels spécifiques semblant bien, pour leur part, devoir être analysés en contrat d'entreprise.

Notre étude ne portera pas, concernant les garanties, sur les hypothèses plus rares de mise à disposition de logiciels spécifiques indépendamment du contrat de développement, analysées en louage de choses.

Le choix entre la qualification de contrat d'entreprise ou de contrat de vente pour une cession du droit d'utilisation d'un logiciel porte à conséquence dans la mesure où les régimes de garantie de conformité et des vices cachés applicables sont, sur certains points, distincts (2). En effet, alors que le code civil ne précise pas quelles sont les garanties applicables au contrat d'entreprise (3), les dispositions de la vente sur la garantie de conformité et des vices cachés ne sont pas toujours transposables à ce type de contrat.

En tout état de cause, après avoir constaté que l'action sur le fondement du défaut de conformité semble plus favorable à l'utilisateur que l'action en garantie des vices cachés eu égard à leurs conditions de mise en oeuvre et aux modes de réparation offerts, il sera nécessaire de rappeler la difficulté tenant à tracer le départ entre chacun de ces fondements.

Conditions de mise en oeuvre des obligations de garantie

Alors que doivent être examinées distinctement les conditions de mises en oeuvre, d'une part de la garantie contre les vices cachés et d'autre part des conditions relatives au défaut de conformité, l'étude de la validité des clauses limitatives de responsabilité portera indistinctement sur l'une et l'autre de ces garanties.

Garantie contre les vices cachés

La mise en jeu de la garantie contre les vices cachés nécessite la démonstration de l'existence d'un vice caché dans un bref délai suivant son apparition.

Il est entendu que la mise en jeu de la garantie des vices cachés, qui est de droit en matière de vente, soulève des difficultés dans le domaine des contrats d'entreprise dont l'objet ne porte pas sur la réalisation d'un bien corporel. Ainsi, lorsque la fourniture du logiciel relève de cette catégorie de contrat (contrat de développement, par exemple), l'application de la garantie des vices cachés risque de se heurter au caractère intellectuel de la prestation (4).

Existence d'un vice caché

L'appréciation de l'existence d'un vice caché est une question de faits qui relève de l'appréciation souveraine des juges du fond. Selon les termes même de l'article 1641 C. civ., un défaut constitue un vice s'il rend le bien impropre à l'usage auquel il est destiné (5), sachant que les juges n'ont pas d'analyse systématique et procèdent selon les cas à une analyse in abstraction ou in concreto (6). Le vice doit être caché en ce sens que l'utilisateur ne doit pas avoir été en mesure de le déceler lors de la délivrance. A cet égard, l'obsolescence d'un bien ou l'usure normale ne pourra pas être considérée comme un vice caché (7). De plus, l'application de ce fondement suppose que l'on admette que le vice puisse s'apprécier différemment dans le temps. Jusqu'en 1999 le progiciel n'était pas vicié, au 1er janvier 2000 il le devient. A supposer que les magistrats admettent cette analyse, la question de l'espérance de vie du logiciel sera déterminante : le logiciel était-il censé fonctionner après le 1er janvier 2000 ?

S'agissant du passage à l'Euro, seuls les logiciels commercialisés après l'adoption définitive de ce changement ou pour lesquels le fournisseur s'est engagé sur la prise en compte de cet événement, pourront s'ils se révèlent en fait inadaptés, être le cas échéant considérés comme viciés. On précisera à cet égard que la date du 1er janvier 1999 sera vraisemblablement très prochainement adoptée comme date de passage à la monnaie unique mais que la liste des Etats membres concernés par cette date reste à établir (8).

Exercice de l'action dans un bref délai

L'action en garantie des vices cachés doit être exercée dans un bref délai à compter de la découverte du vice. Les nombreux articles de presse parus depuis plus de six mois, et même les conférences entières dédiées au thème du passage à l'an 2000, ou encore la proximité de cette date, permettent maintenant d'attirer l'attention sur ce "vice" potentiel du logiciel. Ainsi, les utilisateurs ont le devoir de vérifier très rapidement leurs logiciels au regard de cette difficulté. A défaut, le bref délai sera rapidement expiré. D'ailleurs, bon nombre d'entreprises utilisatrices ont achevé le recensement des programmes posant problème pour une utilisation après le 1er janvier 2000. Ainsi, il deviendra bientôt difficile de soutenir que l'on vient de découvrir le vice. Les utilisateurs qui souhaitent agir sur ce fondement doivent donc intenter leurs actions sans plus attendre.

La contrainte tenant au respect du bref délai s'applique uniquement en matière de vente, la jurisprudence ne l'ayant pas retenue pour les contrats d'entreprise (9).

Pour le passage à l'Euro, l'appréciation en cas de possible mise en jeu de la garantie des vices cachés du point de départ du bref délai est incertaine. Est-ce la date d'annonce de la décision, la date de livraison du logiciel ou encore la date de changement effectif de la monnaie ?

Garantie de délivrance conforme

Le fournisseur d'un logiciel, standard ou spécifique, est encore débiteur d'une obligation de délivrance conforme.

En matière de contrat de vente portant sur la livraison d'un bien corporel, l'obligation de délivrance conforme est une obligation de résultat. En matière de logiciel spécifique, la nature de l'obligation varie en fonction de la complexité de la prestation fournie et de l'importance de la prestation intellectuelle par rapport à la prestation matérielle. En fonction de ces éléments, l'obligation sera de résultat ou de moyens.

Appréciée sous l'angle des intérêts de l'utilisateur, une action sur le fondement d'un défaut de délivrance conforme présente l'avantage, par rapport à l'action sur le fondement des vices cachés, de ne pas être soumise au bref délai. Un autre avantage attaché à l'action en défaut de conformité tient à l'absence d'obligation de prouver, comme c'est requis pour l'action contre les vices cachés, que l'usage du logiciel est impossible ou diminué : il suffit de prouver que le logiciel livré n'est pas le logiciel convenu.

Cette appréciation est principalement effectuée lors de la recette du logiciel. Pour l'ensemble des livraisons intervenues depuis que la question de l'an 2000 est posée, les utilisateurs ont donc tout intérêt à vérifier la faculté d'utiliser le logiciel au-delà de l'an 2000. S'ils recettent le logiciel, il sera après difficile de soutenir que celui-ci n'était pas conforme. Il pourrait néanmoins être soutenu que le silence de l'utilisateur sur ce point, lors de la recette, ne saurait être retenu contre lui si le cahier de recette a été établi par le fournisseur. Dans tous les cas, la conséquence du prononcé de la recette en termes de charge de la preuve est importante. En effet, si le client la refuse, le fournisseur du logiciel ne sera dégagé de son obligation de délivrance conforme qu'après avoir prouvé qu'il l'a dûment exécutée (article 1315, al. 2 C. civ.) (10), alors que si le client la prononce, la conformité est présumée acquise et le client doit alors prouver non seulement la non-conformité mais encore qu'il ne pouvait raisonnablement s'en apercevoir lors de la recette. En conséquence, les utilisateurs ont désormais tout intérêt à refuser la recette de logiciels ne traitant pas l'an 2000 correctement ou à émettre une réserve sur ce point.

S'agissant du passage à l'Euro, lorsque le fournisseur s'est engagé à fournir un logiciel adapté à cette nouvelle monnaie, se pose la question de savoir si on peut en effectuer d'ores et déjà le contrôle (pour les logiciels supposés adaptés à ce jour) ou s'il faut attendre que la réglementation soit précisée ou encore la date effective de changement de monnaie.

Clauses limitatives ou exclusives de responsabilité

La présomption de mauvaise foi du vendeur professionnel, établie par la jurisprudence en application de l'article 1643 C. civ. pour déclarer nulles les clauses exclusives de responsabilité au titre des vices cachés, n'a pas été étendue au cas de responsabilité pour défaut de délivrance conforme ni au cas de responsabilité en exécution d'un contrat d'entreprise.

Ainsi, la présomption de mauvaise foi ne jouant pas, la validité des clauses organisant la responsabilité sera le cas échéant analysée à travers le spectre de la loi du 1er février 1995 sur les clauses abusives ou de la jurisprudence déclarant ces clauses nulles : absence d'objet si elles portent atteinte à l'essence du contrat, si elles sont abusives comme imposées dans une convention qui n'a pas de rapport direct avec l'activité professionnelle de l'utilisateur (11) ou qui résulte d'un abus de position dominante (12). Les critères ainsi posés sont moins stricts que celui d'une présomption systématique de mauvaise foi du vendeur professionnel et permettent ainsi d'écarter les clauses exclusives ou limitatives de responsabilité dans un nombre plus réduit de cas.

Modalités de réparation

L'utilisateur qui souhaite mettre en jeu la garantie de son fournisseur/vendeur de logiciel pourra obtenir soit la résolution de la vente ou la réfaction du prix de vente (selon l'importance des défauts cachés), s'il agit sur le fondement d'un vice caché, soit l'exécution forcée s'il se fonde sur un défaut de conformité ; ce dernier mode de réparation pouvant dans de nombreuses circonstances être bien préférable à la réfaction du prix ou à une résiliation. Si l'exécution forcée est impossible, l'article 1142 permettra d'obtenir des dommages-intérêts.

Le défaut de délivrance, une fois constaté, ouvre droit à la réparation du préjudice en résultant, sans que la démonstration de mauvaise foi du fournisseur ne soit requise (article 1611 C. civ.). En revanche, en matière de vices cachés, les dommages-intérêts ne sont dus que dans l'hypothèse de mauvaise foi du vendeur (article 1645 C. civ.).

En tout état de cause, dans l'un et l'autre cas, le droit à dommages-intérêts est néanmoins limité par les dispositions de l'article 1150 C. civ. : le dommage provenant de l'impossibilité du logiciel de prendre en compte le passage à l'an 2000 était-il un dommage prévisible au moment de la conclusion du contrat ? Si aujourd'hui ce dommage semble clairement prévisible pour les logiciels récemment acquis, tel n'était généralement pas le cas il y a dix ou quinze ans pour les logiciels alors acquis.

Pour le passage à l'Euro, la possibilité du dommage n'existera que lorsque l'on sera certain du changement de monnaie et qu'à la date de ce changement, le logiciel en question sera en fonctionnement.

Champ respectif des deux garanties

La délicate question de savoir distinguer un vice caché d'un défaut de conformité se pose en informatique comme dans les autres domaines de la vie économique. Sur le plan des principes, la question du champ respectif d'application de l'action contre les vices cachés et de l'action en défaut de délivrance conforme semble aujourd'hui recevoir une réponse unifiée par les diverses chambres de la Cour de cassation.

Traditionnellement, la troisième chambre de la Cour de cassation a retenu une conception étroite du défaut de conformité et exclu ainsi tout concours de qualification entre le vice caché et le défaut de conformité pour une même défaillance (13) ; elle a été sur ce point rejointe par la première chambre civile depuis un revirement amorcé par un arrêt du 5 mai 1993, puis par la chambre commerciale depuis un arrêt du 26 avril 1994 (14). La Cour de cassation considère désormais que si le défaut rend le bien impropre à l'usage auquel on le destine, selon les termes de l'article 1641 C. civ., il s'agit d'un vice caché et non d'un défaut de conformité. Il y a tout lieu de penser que cette position sera appliquée aux litiges portant sur un logiciel.

Néanmoins, d'éminents auteurs ont remarqué la difficulté pratique de la mise en oeuvre de la distinction conceptuelle maintenant retenue (15). Pour effectuer cette mise en oeuvre, un premier critère de distinction d'ordre chronologique a été proposé (16) : le défaut de délivrance conforme devrait être constaté dès la prise de livraison alors que les vices cachés se révéleraient lors de l'usage du logiciel. Cette analyse présente certaines limites toutes les fois que les caractéristiques du logiciel se révèlent uniquement à l'usage, notamment lorsque chaque caractéristique ne fait pas l'objet d'une vérification lors de la livraison. Tout laisse à penser que le passage à l'an 2000 n'a pas donné lieu à une telle vérification pour les logiciels fournis jusqu'à une époque récente, dans certains cas.

Pour le passage à l'Euro, la possibilité de vérification avant la survenance de l'événement lui-même est encore plus complexe. Cette première analyse selon un critère chronologique peut être alors complétée par une analyse sur la fonctionnalité. Le défaut de conformité est apprécié par rapport aux fonctionnalités convenues dans la convention des parties alors que le vice caché est apprécié en fonction des fonctionnalités normalement attendues de la chose (17). La distinction entre les fonctionnalités expressément incluses dans le champ contractuel et celles qui ne le sont pas pourrait, dans certains cas, conduire à retenir les vices cachés comme fondements de l'action portant sur le passage à l'an 2000.

En conclusion, il peut être observé que si la distinction entre les deux fondements est nette dans son principe, elle est encore floue en pratique. Il convient, de ce fait, de ne pas exclure la possibilité d'invoquer successivement, à titre principal et à titre subsidiaire, l'un et l'autre de ces fondements dans les demandes en justice (18). Dans ce cas néanmoins, il faudra préciser de quelle manière les conditions d'application pour chacun des deux fondements juridiques sont réunies et ne pas "compter sur une terminologie ambiguë pour laisser au juge le soin de la qualification" (19).

Obligations de maintenance

Dans quelle mesure le contrat de maintenance peut-il constituer un fondement aux prestations d'adaptation d'un logiciel pour qu'il puisse fonctionner après le 1er janvier 2000 ou encore pour supporter le passage à la monnaie unique ? La réponse devra être au cas par cas. En effet, le contrat de maintenance est un contrat d'entreprise dont l'objet est déterminé par la volonté des parties dans chaque situation particulière et sans pouvoir être défini en fonction d'un cadre juridique établi ou de définitions légales. Néanmoins, en marge de toute référence officielle ou de cadre juridique, la pratique a établi une distinction majeure entre les prestations de maintenance curative et les prestations de maintenance évolutive.

Objet du contrat de maintenance

Selon la définition officielle de l'Afnor d'avril 1991 (20), l'expression "maintenance" est réservée au matériel. La pratique n'a toutefois pas abandonné son utilisation également pour le logiciel.

De la même façon, si l'expression "suivi" a été officiellement proposée pour le logiciel, elle n'est pas systématiquement employée dans les conventions. On entend par suivi : "l'ensemble des améliorations fonctionnelles et des performances apportées à chaque nouvelle version d'un logiciel" (21). Les conventions n'utilisent pas nécessairement ces définitions officielles et les expressions de "maintenance curative" et de "maintenance évolutive" sont en pratique aussi utilisées pour les logiciels.

Au-delà de diversités d'expression, les idées se retrouvent à la lecture des contrats : un premier type de maintenance permet de corriger les erreurs de programmation, un deuxième type permet d'améliorer les fonctionnalités.

En conséquence, en l'absence de cadre déjà établi, il conviendra de déterminer à la lumière des termes de chaque convention, si l'adaptation au troisième millénaire pourrait relever ou pas des prestations de maintenance convenues.

Les distinctions établies par la pratique

L'adaptation permettant au logiciel de passer l'an 2000 ou à la monnaie unique est-elle assimilable à une correction technique relevant de la maintenance curative ou à une amélioration fonctionnelle relevant de la maintenance évolutive ?

Dans la mesure, par exemple, où le logiciel ne pourra plus fonctionner après le 1er janvier 2000, pourquoi ne pas considérer qu'il s'agit d'une défaillance couverte par la maintenance curative ? Néanmoins, il est également possible de considérer qu'elle relève de la maintenance évolutive, en ce que la modification pourrait constituer en fait une évolution du logiciel. S'agissant du passage à l'Euro, l'événement s'apprécie clairement en une évolution réglementaire.

Dans une situation, à certains égards similaire, concernant l'adoption du nouveau plan comptable en 1982, la cour d'appel de Paris a jugé que l'adaptation du logiciel aux nouvelles caractéristiques légales n'était pas due au titre de la maintenance curative mais devait faire l'objet d'une convention distincte (22). Deux considérations factuelles doivent néanmoins être prises en considération dans la transposition de cette jurisprudence au cas particulier de l'an 2000. D'une part, les magistrats relèvent que les parties avaient négocié en vain les termes d'un contrat distinct de maintenance évolutive ; son absence de signature leur a permis de conclure que la maintenance convenue était simplement d'ordre curatif. D'autre part, l'adoption du nouveau plan comptable n'a pas été considérée comme inéluctable lorsque le contrat fut conclu quelques mois avant cette adoption.

Dans la mesure où la date du 1er janvier 2000 est un événement futur et certain, il se distingue nettement d'autres types d'événements souvent cités comme ne devant pas être pris en compte au titre de la maintenance évolutive qui ne présente pas un même caractère inéluctable (adoption d'un nouveau plan comptable, modification des normes administratives, de dispositions fiscales...). On notera sur ce point la distinction qui pourra être opérée entre le passage d'une part à l'an 2000, et d'autre part à la monnaie unique.

Une analyse au cas par cas semblera nécessaire.

Fondements périphériques à la relation contractuelle

Obligation d'information

L'obligation d'information a la particularité d'être le plus souvent exécutée avant que le contrat soit conclu, alors même que son non-respect entraîne une responsabilité contractuelle.

Concernant notre sujet, certains auteurs (23) estiment que cette obligation génériquement appelée de "conseil" ne peut recevoir application pour le passage à l'an 2000, considérant que cet événement est connu de tous et qu'il ne peut donc être reproché au fournisseur de ne pas en avoir informé son client, celui-ci étant tenu de se prémunir contre ses conséquences. Une telle position s'appuie notamment sur un arrêt de la Cour de cassation du 20 novembre 1991 (24) selon lequel : "...l'obligation de conseil ne s'appliquait pas aux faits qui sont de la connaissance de tous...".

S'il est incontestable que la connaissance du client a un impact important sur la solution juridique, en l'espèce la solution ne résulte pas directement de l'application de cette jurisprudence. En effet, la question à laquelle nous sommes confrontés n'est pas de savoir s'il appartenait au fournisseur d'informer son client de l'existence même du passage à l'an 2000, fait inéluctable par excellence, mais plutôt de l'informer sur le fait que son logiciel, objet du contrat de licence, ne "passait" pas l'an 2000. Le même raisonnement peut être fait pour la monnaie unique.

L'obligation d'information du fournisseur de système d'information à l'égard du client profane a été admise en jurisprudence dans les années 1970 (25). Certes, elle a depuis fait l'objet d'évolution et d'assouplissement, notamment au regard des qualités de professionnel et de profane, mais le principe demeure. Si la jurisprudence la désigne uniformément sous l'appellation d'obligation de conseil, l'obligation d'information est traditionnellement subdivisée en trois types d'obligation : l'obligation de renseignement, l'obligation de conseil proprement dite et l'obligation de mise en garde.

L'obligation de renseignement consiste essentiellement à mettre à la charge de celui qui fournit le logiciel, l'obligation de renseigner l'utilisateur sur les caractéristiques, notamment techniques dudit logiciel. Le défaut de gestion de l'an 2000 ou de gestion de l'Euro ne peut généralement s'analyser en une "caractéristique" du logiciel, celle-ci s'appréciant de manière positive, et n'ayant donc pas pour objet de souligner une limite.

En revanche, l'obligation de conseil apparaît mieux adaptée mais seulement dans un nombre limité de cas. Généralement définie en jurisprudence comme mettant à la charge du fournisseur l'obligation de "préconiser" à son client un produit qui correspond à son besoin, il est évident que la portée d'une telle obligation s'apprécie différemment selon que le client est plus ou moins averti et/ou selon que le fournisseur aura pu identifier plus ou moins précisément ledit besoin, par exemple la recherche d'un produit qui dure au-delà de l'an 2000. Ainsi à chaque fois que le fournisseur connaissait l'existence d'un tel besoin chez son client et qu'il a préconisé un produit n'y répondant pas, alors que d'autres correspondant tout autant aux autres besoins du client bénéficiaient en plus de l'avantage de gérer le passage à l'an 2000, on pourra s'interroger sur le manquement du fournisseur à son devoir de conseil.

L'obligation de mise en garde, troisième type de l'obligation d'information, consiste en l'obligation pour tout fournisseur d'un système d'information, d'attirer l'attention de son client sur les risques que la mise en place d'un tel système peut faire courir à celui-ci, et notamment s'il existe un risque de désorganisation.

Appliquée au cas d'espèce, cette obligation consisterait donc pour le prestataire à alerter son client sur le défaut de prise en compte, par le logiciel, du passage à l'an 2000, ou à l'Euro, au risque que l'entreprise de ce dernier soit désorganisée. Il semble bien qu'il y ait avec cette obligation un fondement pertinent, la jurisprudence relevant généralement que le fournisseur doit anticiper sur le danger qu'une informatisation incohérente pourrait engendrer (26).

Toutefois, l'application de ce fondement, qui semble permettre la mise en jeu de la responsabilité du fournisseur lorsque celui-ci avait connaissance du fait que son logiciel constituait un risque pour son client, doit être doublement nuancée.

En premier lieu, il convient de souligner l'importance croissante en jurisprudence de la prise en compte du rôle du client et notamment d'une tendance au rétablissement d'un certain équilibre entre les compétences du prestataire et celles de son client.

En second lieu, s'il est clair que les logiciels acquis en 1996 sont quasiment tous censés pouvoir continuer à être exploités au-delà de l'an 2000, pour les produits plus anciens, il connivent de prendre en considération la durée habituelle de vie du type de logiciels considéré. Cette question doit être appréciée à la date d'acquisition du produit.

S'agissant de l'Euro, tant que la décision n'est pas définitive, peut-on mettre à la charge du fournisseur une obligation de mise en garde à cet égard ?

Droit de la propriété intellectuelle

Depuis la loi du 10 mai 1994, l'utilisateur licite d'un logiciel peut exercer les droits patrimoniaux reconnus à l'auteur, sans l'autorisation de ce dernier, dès lors qu'il s'agit de permettre l'utilisation du logiciel de manière conforme à sa destination, le législateur visant expressément l'hypothèse de la correction (27).

Or, il ne semble pas contestable que si les résultats générés par le logiciel sont erronés du fait de la non-prise en compte du passage à l'an 2000 ou à la monnaie unique, il y aura utilisation du logiciel de manière non conforme à sa destination. En conséquence, on pourrait être tenté de soutenir que l'hypothèse du passage à l'an 2000 permet à l'utilisateur de procéder lui-même à l'adaptation nécessaire au titre de l'article L. 122-6.1 du CPI.

Cette solution, séduisante sur le plan théorique, pose cependant une question relative à la portée du droit ainsi reconnu à l'utilisateur, étant ajouté que la mise en oeuvre de ce droit semble bien limitée. On notera cependant que les développements ci-dessous, eu égard au caractère inéluctable de l'an 2000, auront vocation à s'appliquer plus aisément dans ce dernier cas que pour l'adoption de la monnaie unique.

L'étendue du droit reconnu à l'auteur

La question à laquelle il convient de s'attacher en l'espèce est de savoir si le droit reconnu par la directive européenne du 14 mai 1991, puis par la loi française du 10 mai 1994, autorise l'évolution du logiciel ou uniquement sa correction. Sans prendre position sur la qualification technique (correction ou modification substantielle) de ce qu'il convient de faire comme opération pour qu'un logiciel gère l'an 2000 ou la monnaie unique, il ne semble pas contestable, par analyse stricte de la lettre de l'article L.122-6-1 du code de la propriété intellectuelle, que l'utilisateur est autorisé à "adapter" le logiciel, ce qui comprend certes la correction des erreurs mais aussi toute intervention tendant à l'amélioration du logiciel, sous réserve bien entendu que l'objectif soit de maintenir celui-ci dans le seul cadre de la destination dudit logiciel, c'est à dire "ce pour quoi il a été conçu".

Bien avant que la question se pose pour l'an 2000, la doctrine s'est largement prononcée sur ce qu'il fallait entendre par ce droit de l'utilisateur, étant précisé qu'il n'existe pas de décision jurisprudentielle sur ce point.

Le professeur Huet estime que cette disposition octroie de larges pouvoirs à l'utilisateur, et notamment le droit d'adapter le logiciel à ses besoins propres, c'est-à-dire le droit de le modifier pour permettre une exploitation du logiciel "dans les meilleures conditions" (28). Au contraire, le professeur Vivant estime que seule la correction d'erreurs est permise au titre de cet article, justifiant sa position par le fait que la directive européenne ne visait que cette seule hypothèse et qu'il ne convient donc pas d'autoriser l'utilisateur "...à faire évoluer le programme..." (29).

Il semble cependant qu'entre l'évolution du programme, au sens où l'entendent les informaticiens, c'est-à-dire généralement l'apport d'améliorations techniques ou la création de nouvelles fonctionnalités, ce que ne semble pas permettre l'article L.122-6-1 du code précité, et la seule correction d'une anomalie, ce qui est certainement permis par cet article, il existe divers degrés d'évolution. Or, il ne paraît pas contestable que le passage à l'an 2000 ou à l'Euro relèvent des catégories couvertes par cet article sauf à le vider de toute substance.

Il se trouve cependant que sa mise en oeuvre risque de rester quasi impossible en pratique.

Une portée pratique limitée

En premier lieu, il est incontestable que la loi française n'a pas interdit au titulaire des droits de se réserver par contrat la faculté de faire lui-même ces corrections, le caractère d'ordre public de cette disposition ne concernant pas les modalités d'exécution de ce droit à la correction. Ainsi, l'utilisateur se verra généralement opposer une stipulation par laquelle seul l'éditeur du logiciel concerné aura la faculté de mettre en oeuvre le droit dont l'utilisateur est pourtant le bénéficiaire.

En second lieu, il apparaît que le droit ainsi reconnu à l'utilisateur n'a pas comme corollaire de créer au profit de l'utilisateur un droit systématique d'accès aux sources du logiciel (30), ce qui réduit substantiellement la portée de cette disposition dès lors que, pour une grande majorité des cas, la correction ne pourra se faire sans un accès aux sources. Certes, on pourra soutenir qu'une décision de la cour d'appel de Bordeaux (31) a reconnu un droit du client, dans le silence du contrat, à se faire communiquer les sources du logiciel qu'il utilise pour en assurer la maintenance, et qu'un arrêt plus récent rendu par la cour d'appel de Nîmes autorisait l'utilisateur à accéder aux codes sources pour suppléer à la carence de son cocontractant (32). On notera cependant que ces décisions antérieures à la loi de 1994 concernaient des licences pour des logiciels spécifiques (33).

On soulignera aussi que l'utilisateur qui aura pris soin de demander à son fournisseur, lors de l'acquisition du logiciel, de déposer les codes sources auprès d'un séquestre, bénéficiera d'un moyen complémentaire. On peut en effet imaginer que le refus du fournisseur de procéder gratuitement à la correction ou de communiquer les sources pour que l'utilisateur y procède lui-même puisse être assimilé à une défaillance au sens de certains contrats de séquestre ou de règlements d'organismes dépositaires de sources (34).

Enfin, le texte de l'article L.122-6-1 du code de la propriété intellectuelle est insatisfaisant sur deux autres points, d'une part, en ce qu'il fait du bénéficiaire de ce droit le seul utilisateur, ce qui exclut de principe les cas, pourtant nombreux, de tierce maintenance, d'autre part, en ce qu'il ne précise pas si la mise en oeuvre de ce droit est gratuite ou payante (35).

On le voit, chacun des fondements étudiés peut susciter un débat juridique intéressant. A la vérité, chaque fondement doit s'apprécier au cas par cas, en prenant en compte certes les dispositions contractuelles mais aussi les compétences de l'utilisateur et la date d'acquisition du logiciel.

(1) Pour mémoire, l'article L. 122-6-3ème du code de la propriété intellectuelle envisage le cas de la vente d'un exemplaire du logiciel pour énoncer que la règle de l'épuisement du droit est susceptible de limiter le droit de mise sur le marché, attribut du droit d'exploitation du logiciel.

(2) Les différences portent sur l'existence même de la garantie contre les vices cachés pour les contrats d'entreprise relatives à des prestations incorporelles ou les clauses limitatives ou exclusives de responsabilité.

(3) A l'exception du contrat de construction immobilière.

(4) Ph. Gaudrat, J. Cl. Droit des entreprises commerciales, fasc. 250 n° 8 et Lamy informatique 1996, n° 1119 et 1197 contra I. de Lamberterie, J.Cl. Distribution fasc 735, n° 142, J. Huet, Les contrats spéciaux, Litec 1996, 32253-32263 et 32264.

(5) J. Huet, Les contrats spéciaux, n°11318.

(6) J. Huet ibid et A. Benabant, Conformité et vices cachés dans la vente : l'éclaircie D. 1994, Chron. p. 195.

(7) A contrario, une usure trop rapide pourrait être constitutive d'un vice caché, ibid Huet, Com 27 novembre 1973, bull civ IV, n° 345.

(8) Voir propositions de règlements du Conseil sur l'introduction de l'Euro (art 1091 (4) Ce) et sur certaines dispositions y afférentes, JOCE, COM (96) 499.

(9) Lamy informatique 1996 n°1126 et J. Huet, Les contrats spéciaux, Litec 1996 n° 32267.

(10) A. Benabent, Conformité et vices cachés dans la vente : l'éclaircie. D. 1994, Chron. p. 195.

(11) C. Cass. 1er, 3 janvier 1996. JCP Ed. G. n° 23, II 22654.

(12) Décision ODA du Conseil de la concurrence n° 90-D-31 relative à des pratiques relevées sur le marché de la publicité dans les pages jaunes des annuaires officiels des abonnés au téléphone.

(13) S'opposait à cette conception étroite, une conception plus large de la notion de défaut de délivrance, laquelle devait nécessairement inclure les vices cachés dans la mesure où les parties n'ayant pu convenir de délivrer une chose atteinte d'un vice, si tel était le cas, il y avait nécessairement délivrance non conforme.

(14) L. Leveneur, JCP. éd. E., 1994 n° 41, 607 Cass. com. 26 avril 1994.

(15) L. Leveneur, JCP. éd. E., 1994 n° 41, 607 Cass. com. 26 avril 1994 et J. Huet, Les contrats spéciaux, Litec 1996 n° 11229.

(16) J. Huet, Les contrats spéciaux , Litec 1996 n° 11229.

(17) L. Leveneur, JCP. éd. E., 1994 n° 41, 607 Cass. com. 26 avril 1994.

(18) En ce sens Ch. Atias, La distinction du vice caché et de la non-conformité, Dalloz 1993 Chron,. 120 p. 261.

(19) Cette démonstration est nécessaire pour éviter tout risque de concours de qualifications d'une même défaillance sur ces deux fondements juridiques, sanctionné par la Cour de cassation, pour non-respect de l'article 4 du NCPC. L'article 4 du NCPC prévoit que : "l'objet du litige est déterminé par les prétentions respectives des parties". Ibid.

(20) La maintenance est l'"Ensemble d'actions tendant à prévenir ou à corriger les dégradations d'un matériel afin de maintenir ou de rétablir sa conformité aux spécifications". Il est encore précisé en note que "Ce terme ne doit pas être employé pour désigner les améliorations fonctionnelles ou de performances apportées à chaque nouvelle version d'un logiciel".

(21) Recommandation A7-84 Groupe permanent d'étude des marchés d'informatique et de communication BO de la concurrence et des prix, 21 septembre 1984 p. 290.

(22) CA Paris 20 mai 1986, CCEC c/ Philips.

(23) Danièle Véret, "Qui doit payer les frais du passage à l'an 2000 ?", 01 Informatique, 29 mars 1996.

(24) Civ. 3ème, 20 novembre 1991, Bull. Civ. III, n° 284.

(25) CA Paris, 12 juillet 1972, JCP 74.II.17603 ; Trib. Com. de la Seine, JCP 71.II.16752.

(26) On peut citer à titre d'exemple un jugement récent du tribunal de commerce de Nanterre selon lequel manque à son obligation de conseil (au sens d'obligation d'information) le fournisseur qui n'a pas informé le client de façon explicite sur les limites du logiciel qu'il offre ; Trib. Com. Nanterre, 30 juin 1995, inédit, cité dans la revue Expertises, mai 1996, p. 174.

(27) Article L.122-6-1 du code de la propriété intellectuelle.

(28) Jérôme Huet, Petites affiches, 6 mai 1992, n° 55, p. 22.

(29) Michel Vivant, JCP ed. E., 1991, Chronique n° 94, p. 484.

(30) Rapport AN du 18 novembre 1993.

(31) CA Bordeaux, 24 septembre 1984, Lexis.

(32) CA Nîmes, 29 novembre 1989, Jcl 1991, éd E II, 15920, ch Vivant et Lucas.

(33) Sur l'accès aux sources, voir Frédérique Dupuis-Toubol, Expertises n° 142, La mise sous séquestre des codes sources de logiciels, p. 292, ainsi que, plus récemment Hervé Croze et Franck Saunier, Logiciels : retour aux sources, JCP 1996, éd E, Etudes et chroniques n° 542.

(34) Voir notamment le règlement général de l'Agence pour la protection des programmes.

(35) L'exigence d'une contrepartie financière apparaît toutefois manquer de légitimité.