Une approche juridique du bug

Le terme de « bug » (ou bogue, en bon français bien moins usité) est largement entré dans le langage courant. Il désigne une erreur ou un dysfonctionnement d’un programme informatique survenant lors de l’utilisation d’un ordinateur, d’un téléphone ou d’un autre objet similaire. Tout le monde en rencontre régulièrement en tant qu’utilisateur ou utilisatrice de logiciel. Mais quelle est la signification d’un bug du point de vue du droit des contrats ? Le bug n’est de toute évidence pas une notion juridique, mais il en est une qui s’en rapproche : le défaut. Le cas échéant, l’existence d’un défaut donne à la partie qui en subit les conséquences certains droits à l’encontre de l’autre, par exemple réclamer une diminution du prix ou se départir du contrat.

Les bases légales applicables pour répondre à ces interrogations varient selon le type de contrat en cause. On peut imaginer principalement les hypothèses suivantes : un logiciel standard est acquis définitivement – que ce soit pour lui-même ou comme partie intégrante d’un hardware (contrat de vente), un logiciel standard est cédé pour une durée déterminée (contrat de licence) ou un logiciel est développé selon les besoins spécifiques d’une clientèle professionnelle (contrat d’entreprise). Les contrats de vente et d’entreprise font tous les deux l’objet de dispositions légales dédiées (art. 184 ss et 363 ss CO), tandis que le contrat de licence est un contrat dit innommé auquel le tribunal appliquera par analogie les normes qui lui semblent pertinentes dans le cas d’espèce (ATF 115 II 255, consid. 2b). Malgré ces différences auxquelles les juristes veilleront à prêter attention, les contours de la notion de défaut restent sensiblement les mêmes. Pour les besoins du présent blog, l’on peut donc s’en tenir à une sorte de conception générale du défaut.

Ceci posé, un bug est-il un défaut ? La réponse claire est : pas forcément. La notion juridique de défaut est plus restrictive. Il est en effet inévitable que tout logiciel soit affecté par un certain nombre de bugs, sans que ceux-ci ne soient toujours juridiquement significatifs (cf. parmi d’autres U. Sury, Digital in Law – Informatikrecht, 2^e éd., Berne 2021, p. 115). La Cour de justice du canton de Genève a bien résumé la problématique dans un arrêt de 2018 : « En matière informatique, il est admis qu’aucun logiciel ne peut être totalement exempt de pannes et d’autres dysfonctionnements ; le 0% d’erreurs est un objectif considéré comme inatteignable. La présence d’une erreur ou bug, au sens où l’informatique l’entend, ne signifie pas toujours que l’on se trouve en présence d’un défaut au sens du droit […] » (Chambre civile, ACJC/615/2018 du 8 mai 2018, consid. 4.1.4).

Le défaut est une notion principalement subjective, qui dépend de ce qui a été convenu dans le contrat : est défectueux l’objet qui diverge de l’accord des parties. On reconnaît toutefois aussi une forme de défaut objectif, dans le sens où l’objet du contrat doit également avoir les propriétés et les qualités généralement attendues d’un objet du même genre (C. Müller, Contrats de droit suisse, Berne 2021, N 310 et N 2058-2060). Ce deuxième type de défaut repose sur les règles de la bonne foi (art. 2 CC), dont on déduit qu’il n’est pas nécessaire de stipuler dans le contrat des qualités jugées normales. L’article 197 alinéa 1 CO, relatif au contrat de vente, exprime aussi d’une certaine manière cette double nature : « Le vendeur est tenu de garantir l’acheteur tant en raison des qualités promises qu’en raison des défauts qui, matériellement ou juridiquement, enlèvent à la chose soit sa valeur, soit son utilité prévue, ou qui les diminuent dans une notable mesure ».

On trouve encore étonnamment peu de jurisprudence et de doctrine cherchant à concrétiser la notion de défaut de façon plus détaillée pour le domaine informatique. On en est par conséquent réduit à raisonner sur la base des principes généraux présentés ci-dessus, à l’image du Tribunal fédéral qui s’est contenté d’indiquer que les erreurs d’un logiciel ne sont des défauts au sens juridique que lorsqu’elles entraînent l’absence d’une caractéristique garantie dans le contrat ou qu’elles compromettent la fonctionnalité du logiciel pour l’utilisation prévue (ATF 124 III 456, consid. 4c/aa). Ce à quoi l’on pourrait ajouter l’hypothèse où en raison de ses nombreux bugs, le logiciel s’écarte des standards généralement attendus en la matière.

Force est de constater que ce genre de réponse laisse subsister beaucoup d’incertitudes, car elle repose largement sur l’appréciation des parties ou du tribunal. Une solution recommandée serait dès lors de spécifier dans le contrat quelles sont les qualités du système promises par le ou la prestataire, en termes aussi précis et objectifs que possible (cf. U. Sury, op. cit., pp. 116-117). On peut imaginer que soient définis par exemple un taux d’erreur maximal, une certaine vitesse d’exécution des tâches ou encore, bien que cela ne concerne plus la notion de défaut en tant que telle, les modalités d’intervention du support technique chargé de résoudre les problèmes. Il pourrait aussi être intéressant de s’inspirer de la figure des « Key Service Levels » (cf. à ce propos J. de Werra, Les contrats de niveau de service, in : CEDIDAC, Internet 2005, Lausanne 2005, p. 124), utilisée notamment en matière d’outsourcing informatique pour désigner les services qui doivent être assurés en priorité. Selon cette idée, les parties pourraient définir les fonctionnalités essentielles du logiciel pour lesquelles le niveau d’exigence est plus élevé.

La solution qui précède n’est bien sûr envisageable que pour les contrats conclus entre professionnels et réellement négociés. S’agissant des logiciels de masse développés par les géants de l’informatique, le problème a déjà été réglé à votre désavantage dans les conditions générales que vous avez acceptées sans les avoir lues !