L'an 2000, l'ordinateur et le droit | Réseau juridique



L'an 2000, l'ordinateur et le droit


AVIS AUX LECTEURS

Le présent texte constitue un ouvrage de référence faisant partie intégrante de la "Banque de textes juridiques historiques" du Réseau juridique du Québec.

L'information disponible est à jour à la date de sa rédaction seulement et ne représente pas les changements législatifs et jurisprudentiels en vigueur depuis sa rédaction.



Michel A. Solis et Geneviève Cabana, avocats - Michel A. Solis & Associés, Montréal


Contenu

À qui la faute?

Les garanties

La responsabilité

Quoi faire?

Conclusion


L'approche de l'an 2000 a sonné le glas chez les utilisateurs de systèmes informatiques depuis la découverte de l'incompatibilité de plusieurs logiciels avec le passage au deuxième millénaire.

La majorité des logiciels ne sont pas compatibles avec l'an 2000, considérant qu'ils ont été développés pour calculer les années à l'aide de deux (2) champs au lieu de quatre (4) ("97" au lieu de "1997") et assument que toutes les dates se situent dans le 20e siècle.

Ainsi, si on demande au logiciel d'effectuer un calcul impliquant une année située au-delà de 1999, le système fournira des résultat inexacts ou encore "plantera". Si ces systèmes ne sont pas modifiés en conséquence, ils pourraient occasionner des problèmes majeurs aux entreprises pour qui le calcul des années est important, comme par exemple les institutions financières, les compagnies d'assurances, les courtiers etc.

Afin de pallier ce problème, les logiciels doivent être modifiés et ce, avant la date fatidique du 1er janvier 2000. Selon l'industrie, le coût total d'une telle modification pourrait s'élever à 6 milliards de dollars. Mais qui doit en payer le prix? Les producteurs, distributeurs et vendeurs de logiciels ou les acheteurs?

À qui la faute?

Une des premières questions que l'on se pose est comment peut-on se retrouver avec un tel problème aujourd'hui? La réponse est simple: ce type de configuration était auparavant la norme dans l'industrie. Considérant que la mémoire vive était très dispendieuse, on épargnait des sous en utilisant seulement deux champs au lieu de quatre et surtout, les producteurs ne croyaient pas que leurs logiciels seraient encore utilisés des dizaines d'années plus tard, étant donné la rapidité des développements technologiques.

Dans ce cas, est-ce qu'un logiciel développé en 1996 et dont la durée de vie est estimée à cinq (5) ans devrait être compatible avec l'an 2000, ou sinon, comporter un avertissement à l'effet qu'il ne l'est pas? Dans l'affirmative, est-ce que les producteurs de logiciels doivent supporter l'entière responsabilité de cette incompatibilité et ce, dans toutes les situations? Probablement pas, mais comme vous pouvez le constater, ce problème de l'an 2000 pose présentement plusieurs questions.

Le premier réflexe de l'utilisateur du logiciel doit naturellement être l'examen de tous les contrats relatifs audit logiciel, soit le contrat de licence, de support etc.

Les garanties

    Le Code civil du Québec

    De manière générale, lorsqu'il n'y a aucune limitation ou exclusion de garantie à l'intérieur d'un contrat de vente, la garantie légale de qualité du bien vendu s'applique. C'est-à-dire que, selon l'article 1726 du Code civil du Québec:

      "Le vendeur est tenu de garantir à l'acheteur que le bien et ses accessoires sont, lors de la vente, exempts de vices cachés qui le rendent impropre à l'usage auquel on le destine ou qui diminuent tellement son utilité que l'acheteur ne l'aurait pas acheté, ou n'aurait pas donné si haut prix s'il les avait connus."


    À cet égard, il est important de souligner que cette garantie légale contre les vices cachés s'applique non seulement au vendeur du logiciel, mais aussi au distributeur et au producteur.

    En conséquence, est-ce que le fait qu'un logiciel cesse de fonctionner correctement le 1er janvier 2000 sera considéré comme un vice caché? Probablement dans le cas d'un logiciel développé en 1995 qui a pour fonction principale le calcul des dates, considérant que ce défaut le rendra impropre à l'usage auquel il était destiné.

    Mais qu'en est-il pour un logiciel développé en 1985? Le producteur pourrait peut-être repousser cette garantie en démontrant que le mauvais fonctionnement de celui-ci en l'an 2000 est tout à fait normal et ne survient pas prématurément par rapport à d'autres logiciels similaires, c'est-à-dire du même âge.

    Les contrats de licence

    Par ailleurs, les contrats de licence excluent fréquemment toute garantie explicite ou implicite, incluant toute garantie de qualité, de pertinence pour un usage quelconque, ou quant à l'exactitude, à la performance ou à l'absence d'erreurs dans le logiciel. Dans la mesure où ces exclusions de garanties expresses seraient valides, il deviendrait plus difficile de prouver la responsabilité du producteur quant au non-fonctionnement de son logiciel.

    Toutefois, ces exclusions de garanties pourraient être jugées invalides par un tribunal. En effet, bien qu'un vendeur puisse exclure ou limiter la garantie légale sur le logiciel, il lui est impossible d'exclure ou de limiter sa responsabilité s'il n'a pas révélé à l'acheteur les vices qu'il connaissait et qui affectent la qualité du logiciel. Or, bien qu'il soit plausible que le vendeur ne connaisse pas l'incompatibilité du logiciel avec l'an 2000, il serait surprenant que son producteur ne soit pas au courant...

    En conséquence, même si la garantie du contrat de licence est expirée ou encore, si celui-ci exclut toute garantie ou responsabilité du producteur, il est possible que celui-ci soit malgré tout tenu responsable s'il est démontré qu'il savait que le logiciel deviendrait inutilisable à l'an 2000 et qu'il a délibérément choisi de ne pas en informer l'acheteur.

    Les contrats de licence "shrink-wrap"

    De plus, il est important de rappeler que la validité de telles exclusions de garanties est d'autant plus incertaine si celles-ci sont mentionnées dans un contrat de licence sous forme "shrinkwrap", c'est-à-dire dans un contrat de licence qui est intégré à l'emballage du logiciel et qui, en conséquence, n'est pas signé par l'acheteur.

    Les contrats de support

    D'autre part, les contrats de licence accordent souvent une seule et unique garantie sur le logiciel: celui-ci fonctionnera de façon conforme à la documentation qui l'accompagne et ce, souvent pour une période de temps limitée (comme par exemple 90 jours). Or, la plupart de ces garanties ne seront plus applicables au 1er janvier 2000 et ne seront donc d'aucune utilité à l'acheteur.

    Par contre, si la relation entre les parties survit jusqu'à l'an 2000 par le biais d'un contrat de support, le producteur devra alors respecter la garantie énoncée dans ledit contrat. Or, si celui-ci garantit que le logiciel fonctionnera de façon conforme à sa documentation, il est probable que le producteur soit tenu responsable, considérant que la documentation qui accompagne les logiciels n'exclut habituellement pas le fonctionnement du logiciel en l'an 2000.

pLa responsabilité

Quant à la responsabilité du producteur de logiciel, celle-ci est souvent exclue expressément à l'intérieur du contrat, comme par exemple: "En aucun cas le producteur ne sera-t-il responsable pour toute perte de revenus, profits, ou de données ou pour des dommages spéciaux, indirects, imprévisibles ou punitifs, découlant de ou en rapport avec l'utilisation ou l'incapacité d'utiliser le logiciel (...)." Encore là, une telle limitation de responsabilité pourrait faire obstacle à une action en dommages d'un acheteur contre un producteur.

Néanmoins, il est important de rappeler qu'il est impossible pour le producteur d'exclure sa responsabilité pour le dommage matériel causé par sa faute intentionnelle ou par sa faute lourde, c'est-à-dire par son insouciance, son imprudence ou sa négligence grossière. Est-ce que le fait d'avoir développé et mis en marché un logiciel qui cessera de fonctionner correctement le 1er janvier 2000 pourrait être considéré comme une faute lourde de la part du producteur?

Afin de répondre à cette question, plusieurs facteurs devront être examinés, dont plus particulièrement la durée de vie raisonnablement prévisible dudit logiciel. En effet, la responsabilité d'un producteur quant à un logiciel développé en 1985 sera probablement examinée sous un angle différent de celle d'un producteur quant à un logiciel développé en 1995.

Quoi faire?

La première chose que doit faire un acheteur confronté à un tel problème est de communiquer avec le producteur afin de connaître sa position quant à l'incompatibilité du logiciel: est-ce qu'une solution a été développée quant au problème d'incompatibilité du logiciel, celle-ci est-elle offerte gratuitement?

Dans le cas contraire, c'est-à-dire si le producteur nie toute responsabilité et refuse d'effectuer les modifications requises sur le logiciel, plusieurs acheteurs seront tentés de faire appel à une autre compagnie afin que celle-ci effectue lesdites modifications sur le logiciel.

    Faire modifier le logiciel par un tiers?

    Cependant, cette solution est risquée car les contrats de licence comportent habituellement une clause interdisant à l'acheteur de modifier, désassembler ou décompiler le logiciel et ce, de quelque manière que ce soit. Le fait qu'un tiers modifie le logiciel afin de rendre celui-ci compatible avec l'an 2000 peut donc constituer une violation du contrat de licence et donner ouverture à sa résiliation par le producteur.

    De plus, même en l'absence d'une telle interdiction à l'intérieur du contrat de licence, cette modification du logiciel par un tiers pourrait constituer une infraction à la Loi sur le droit d'auteur et entraîner un recours en dommages-intérêts du producteur contre l'acheteur et la tierce partie ayant modifier ledit logiciel. En effet, l'article 64.2 (2) de la Loi sur le droit d'auteur prévoit:

      "Il est entendu que peut constituer une violation du droit d'auteur ou des droits moraux sur une oeuvre l'incorporation de tout programme d'ordinateur dans un circuit intégré ou de toute oeuvre dans un tel programme."

    Afin de minimiser les risques d'une telle opération, l'acheteur devrait préalablement demander au producteur de rendre le logiciel compatible à l'an 2000 dans un délai raisonnable et qu'à défaut de le faire, il n'aura d'autre choix que de s'adresser à un tiers afin de faire effectuer les modifications requises. Bien que cette solution ne soit pas une garantie contre la résiliation de la licence ou contre toute poursuite éventuelle de la part du producteur, elle démontre à tout le moins la bonne foi de l'acheteur.

Conclusion

Dans le but d'éviter de longs et dispendieux litiges, il serait peut-être plus avantageux pour les producteurs de rendre disponible une solution afin que leur logiciel fonctionne correctement à l'an 2000, comme par exemple en offrant celle-ci gratuitement aux acheteurs de logiciels dont la garantie est encore en vigueur et à moindre coût à ceux dont la garantie est expirée.

À l'avenir, compte tenu de l'incertitude actuelle quant à l'étendue de la responsabilité des producteurs, il serait plus prudent d'aviser les acheteurs de l'incompatibilité du logiciel à l'an 2000, le cas échéant, et d'exclure expressément toute garantie et toute responsabilité à cet égard et ce, à l'intérieur même des contrats de licence.


À jour au 15 novembre 1997

Avis. L'information présentée ici est de nature générale et est mise à votre disposition sans garantie aucune notamment au niveau de son exactitude ou de sa caducité. Cette information ne doit pas être interprétée comme constituant des conseils juridiques. Si vous avez besoin de conseils juridiques particuliers, vous devriez consulter un avocat.

© Copyright 1997 - , Michel A. Solis et Associés, Tous droits réservés