L’action en contrefaçon de logiciel bute souvent sur la démonstration du caractère protégeable du programme. La jurisprudence récente donne des pistes pour comprendre les attentes des tribunaux et identifier les principaux pièges à éviter. L’étude de ces décisions permet de comprendre les étapes nécessaires de la démonstration judiciaire, pour mettre toutes les chances de son côté. 

 

Le juriste confronté à une contrefaçon de logiciel éprouve un sentiment de perplexité lorsqu’il doit formaliser ses demandes et caractériser l’originalité du programme. Sauf à ce qu’il soit informaticien, geek ou concepteur lui-même, il est le plus souvent décontenancé dans cet exercice indispensable mais périlleux. Rappelons qu’il ne peut esquiver cette étape puisque la charge de la preuve incombe au demandeur en vertu de l’article 9 du code de procédure civile, et qu’il n’existe aucune présomption d’originalité¹. Il appartient donc au demandeur d’identifier clairement l’objet dont il revendique des droits, et de tenter d’établir que le programme revendiqué est bien éligible à la protection au regard des critères légaux. Le nombre important d’actions en contrefaçon de logiciels aboutissant à un débouté démontre que cet obstacle délicat n’est pas toujours franchi avec succès par les plaideurs. Essayons de tirer l’enseignement de ces échecs avec modestie. L’étude de la jurisprudence récente devrait permettre d’identifier les principaux pièges, de détecter les attentes des tribunaux afin de mettre toutes les chances de son côté pour franchir l’obstacle. Procédons par étape, pour comprendre ce qu’il faut – ou pas –démontrer.

 

Points clés à retenir sur l’originalité du logiciel 

Avant d’entrer dans le détail du raisonnement juridique, quelques repères permettent de saisir l’essence du débat autour de l’originalité des logiciels : 

• Identifier clairement le logiciel concerné, sa version et ses caractéristiques dès l’assignation. 

• Déterminer et exposer les éléments réellement protégeables, à l’exclusion des simples idées ou interfaces. 

• Comprendre que l’originalité se démontre par les choix créatifs et intellectuels du concepteur, et non par la finalité du programme. 

• Se garder de confondre description et démonstration, la preuve exigeant une mise en lumière du cheminement intellectuel. 

• Écarter les faux critères (nouveauté, investissement, expertise non judiciaire) qui n’ont pas de portée juridique. 

• Retenir que la force de la preuve repose sur la cohérence du raisonnement, et sur la capacité à montrer comment le logiciel porte l’empreinte personnelle de son auteur. 

 

 

I. Au programme : identifier et décrire le logiciel

1. Versions, éditions et éléments du programme 

Le demandeur doit être précis dans son acte introductif d’instance, et identifier précisément le logiciel pour lequel il revendique des droits. Alors qu’une marque ou un brevet sont identifiés par un numéro d’enregistrement, il n’existe pas d’équivalent en matière informatique, à savoir une référence harmonisée obligatoire qui constituerait la carte d’identité du logiciel. Celui-ci reste indentifiable par un numéro de dépôt lorsqu’il a fait l’objet d’un dépôt certifié, comme le numéro unique IDDN délivré par l’Agence de la protection des programmes. À défaut, sa référence commerciale, un numéro de série du fabricant, une marque, un millésime, le numéro d’édition d’une version permettent d’y pallier. Faute d’identification rigoureuse et d’énonciation des caractéristiques revendiquées, une demande en nullité de l’acte introductif d’instance fondée sur l’article 56 du code de procédure civile est à craindre puisque celui-ci impose que soient précisés les moyens en fait et en droit au soutien des demandes. Le défendeur pourrait alors alléguer qu’il est dans l’incapacité de se défendre utilement faute d’identification des droits opposés. C’est ainsi que par une ordonnance du 14 décembre 2022, le juge de la mise en état du tribunal judiciaire de Nanterre² annula une assignation faute d’identification suffisante du programme par sa version. Dans le même sens, la cour d’appel de Versailles rappelle « [q]u’il appartient à celui qui sollicite la protection de son droit d’auteur d’identifier l’œuvre à protéger et les caractéristiques qui fondent son originalité, et ce dès l’assignation, et qu’en l’espèce l’assignation ne permet pas d’identifier les œuvres et versions des logiciels dont la protection est sollicitée, ni n’en décrit les caractéristiques qui auraient été reprises »³. Par ailleurs, selon la Cour de Cassation, les juges du fond ne peuvent relever d’office l’absence d’originalité d’une œuvre de l’esprit sans inviter les parties à présenter leurs observations, dans le respect du principe de la contradiction.⁴

 

2. Description des éléments protégeables  

Il appartient ensuite au praticien de déterminer et décrire avec rigueur les éléments argués de contrefaçon susceptibles de bénéficier de la protection au titre du droit d’auteur. La protection du logiciel correspond à son programme. Peu importe sa finalité et sa destination⁵. Ainsi, sont compris : les logiciels de base, d’application, les progiciels, le code objet ainsi que le code source. Il convient dès lors de décrire avec précision les composantes du logiciel pouvant faire l’objet d’une protection, c’est-à-dire notamment : l’architecture technique et la composition éventuelle des modules, les combinaisons des composantes logicielles, ou encore les techniques de modélisation et de programmation employées. Le logiciel inachevé bénéficie de la protection de la directive⁶. La cour d’appel de Bordeaux a rappelé, dans un arrêt récent, que peut également être protégé un « travail d’ébauche de logiciel qui serait suffisamment avancé pour constituer une étape fonctionnelle du travail dès lors que celui-ci est en soi empreint d’originalité »⁷. Enfin, le matériel de conception préparatoire du logiciel visé dans l’article L. 112-2 du code de la propriété intellectuelle est également éligible à la protection. 

 

3. Sort des éléments exogènes

Certains éléments associés à la conception de solutions informatiques ne relèvent pas de cette protection spécifique. Il en est ainsi de l’interface graphique, du format de fichier, ou du manuel d’utilisation, qui sont considérés comme des créations périphériques ne constituant pas, en elles-mêmes, des expressions du logiciel. Elles sont protégeables par le droit commun du droit d’auteur si tant est qu’ils en respectent les conditions. Conformément au principe général du droit de la propriété intellectuelle, n‘est protégée que l’expression des idées et non les idées en tant que telles, qui demeurent de libre parcours. Ainsi, seule la formalisation de ces idées à travers une suite d’instructions dans le cadre d’un processus peut être protégeable, tandis que l’idée d’un programme appliqué à un domaine d’activité, comportant telle fonctionnalité selon tel langage, est partagé par la concurrence⁸.  

 

 

II. Démontrer objectivement la subjectivité : tout un programme

Une fois les éléments susceptibles de protection identifiés, se pose la question, plus délicate, de l’explicitation puis de la démonstration de l’originalité de chacun d’entre eux, condition indispensable à l’obtention de la protection au titre du droit d’auteur.  

1. De l’explicitation à la démonstration

Comme l’énonce le juge de la mise en état de Nanterre dans l’ordonnance précitée, qui constitue un bréviaire d’une remarquable pédagogie pour le demandeur : « L’originalité n’[est] pas un fait juridique qui se démontre, le cas échéant par présomption, mais une qualification juridique qui s’apprécie ».  Cette appréciation est successive au cours de la procédure. Au stade de l’assignation, elle doit être explicitée, c’est-à-dire qu’il appartient au demandeur de démontrer son existence sans aller jusqu’à lui imposer de caractériser sa pertinence. Selon la même décision : « expliciter n’est pas prouver mais rendre clair et précis ; l’exigence d’explicitation touche à la détermination de la demande et non à la preuve de sa recevabilité ou de son bien-fondé. » À charge pour le demandeur de déterminer la définition objective des éléments subjectifs qui la caractérise pour permettre un débat contradictoire à la fois pertinent et loyal. Cette obligation vise à éviter un ajustement opportuniste de l’assiette des droits par le demandeur en fonction des moyens de défense opposés. Ensuite, il faudra la démontrer dans les conclusions pour que le Tribunal procède à sa qualification. 

 

2. Les critères à démontrer 

Le critère de l’originalité⁹ a été consacré en 1986 dans l’arrêt d’Assemblée plénière Pachot, qui établit le critère de « l’effort personnalisé allant au-delà de la simple mise en œuvre d’une logique automatique et contraignante »¹⁰. La Cour de justice européenne est venue harmoniser cette notion, dans un arrêt de 2009 dit Infopaq. Elle a défini l’originalité d’une œuvre par la notion de « création intellectuelle propre à son auteur »¹¹. La difficulté pour les praticiens tient au fait que, malgré une jurisprudence abondante, les critères utilisés varient de « l’effort personnalisé », à « l’effort intellectuel individualisé », en passant par « l’effort créatif personnel » ou encore par « la marque d’un apport intellectuel du créateur ». La doctrine précise que le terme « effort » ne correspond pas à une appréciation de la valeur ou du mérite, mais se rapporte à l’existence d’une création de forme et à l’empreinte personnelle ¹². 

 

3. Décrire n’est pas démontrer

a. De la description technique à la démonstration créative 

Il appartient au demandeur de prouver l’existence d’un effort constituant un apport intellectuel. Il doit y avoir un véritable exercice de démonstration par le demandeur, et c’est cette étape qui, souvent, est à l’origine du refus de la protection. L’action sera jugée irrecevable si le demandeur ne parvient pas à prouver l’originalité¹³. La description du programme, démarche purement naturaliste, ne saurait valoir démonstration de son originalité.

b. L’insuffisance d’une simple énumération fonctionnelle 

La cour d’appel de Paris a ainsi considéré que le titulaire de droit ne doit pas se contenter « de décrire les fonctionnalités du programme […], le langage de programmation ou le format des fichiers utilisés dans le cadre de ce logiciel pour exploiter certaines de ses fonctions […], mais expose[r] les choix auxquels [il] a procédé dans l’écriture du code et dans la composition, les raisons des interactions des champs et des tables telles la nomenclature […], en développant des fonctions spécifiques »¹⁴. Le titulaire ne doit pas se « borne[r] à énoncer une liste des éléments qu’il considère créatifs, sans exposer quels sont les arbitrages qu’il a été amené à opérer entre les choix qui s’offraient à lui dans la conception du logiciel en cause ».

c. L’importance du cheminement intellectuel de l’auteur 

Au contraire, il doit montrer « le cheminement intellectuel qu’il a suivi et les options qu’il a prises parmi celles qui s’offraient à lui, de manière à placer la juridiction saisie en mesure de procéder à l’analyse in concreto qui lui incombe de la réalité de son effort créatif »¹⁵. En effet, il ne suffit pas de présenter les éléments constitutifs du logiciel ou d’énoncer des généralités pour y accéder. Il est nécessaire d’apporter une véritable démonstration du « caractère réellement arbitraire des choix opérés »¹⁶ ainsi qu’une « preuve d’une personnalisation de la structure du logiciel caractérisant une œuvre de l’esprit protégeable »¹⁷).

d. Les manifestations concrètes de l’originalité 

Ces choix personnalisés doivent se manifester dans l’écriture du code, dans son organisation, ainsi que dans les interactions entre les différents éléments, de manière à permettre au juge de constater que les interactions dépassent une simple logique fonctionnelle, contraignante ou automatique. La cour d’appel de Douai a considéré que « la preuve de l’originalité d’un logiciel, lequel se caractérise par sa structure “interne”, transparente pour l’utilisateur, composée de l’écriture même des instructions du programme source et son enchaînement en une architecture globale, ainsi que par sa structure “externe”, correspondant à l’interface utilisateur, à ses fonctionnalités et à ses aspects télévisuels, doit être démontrée in concreto par le demandeur »¹⁸.

e. L’appréciation globale des choix combinés

La même cour a pu retenir l’originalité du logiciel « dans sa composition, son architecture et son expression au regard des apports intellectuels et personnalisés qu’il comporte et matérialise qu’il est donc le résultat de choix créatifs et arbitraires »¹⁹. Si les moyens employés sont décrits de manière trop sommaire et ne permettent pas d’identifier de véritables choix créatifs, alors l’originalité ne sera pas retenue. La jurisprudence admet tout de même que chaque choix, pris isolément, n’a pas besoin d’être original. Ce qui compte, c’est que, si « ces choix pris individuellement peuvent ne pas être originaux, ils traduisent toutefois, ainsi combinés, des choix arbitraires et spécifiques »²⁰.  

f. La démonstration par les interactions et la combinaison 

La preuve de l’originalité se concrétise par les liens entre les éléments, plus que les éléments en eux-mêmes. La démonstration se matérialise par l’association et la combinaison, les interactions entre les éléments entre eux, comme par exemple le choix du langage avec un processeur spécifique, le choix d’une ergonomie avec une architecture, les interactions entre les champs et les tables (les raisons éventuelles de leur regroupement) et la nomenclature, le rôle de l’algorithme. L’exposition des choix d’écritures et de composition contribue à cette démonstration. L’explication peut s’effectuer étape par étape, en explicitant chacun des choix opérés et en veillant à démontrer que ces choix ne résultent pas uniquement de contraintes fonctionnelles, mais relèvent d’une véritable liberté de conception. 

 

 

III. « Erreur 404 » : les moyens théoriquement inopérants

Échouer dans sa démonstration, c’est soit ne pas assez expliquer, soit expliquer ce qui n’est pas utile. C’est cette deuxième option qui nous intéresse ici. 

1.  La comparaison concurrentielle et la nouveauté du programme

a. La tentation de la comparaison avec les logiciels existants 

Certaines décisions se réfèrent de façon inappropriée à la nouveauté du logiciel, en opérant une comparaison avec les programmes antérieurs. Ainsi, certains arrêts estiment que les choix opérés doivent être « différents de la pratique traditionnelle ou de ceux des concurrents »²¹. L’action a été rejetée faute d’« indication pertinente relative à l’apport créatif par rapport à l’état de la technique existante dans le domaine des logiciels d’informatisation des services d’archives »²², ce qui empêcherait l’appréciation de l’originalité du logiciel prétendument contrefait. 

b. La confusion entre nouveauté et originalité 

 Il a déjà été considéré que la démonstration ne repose pas sur la seule production des codes sources du logiciel concerné, mais résulte de « la comparaison avec les codes sources des autres logiciels déjà existant et assurant les mêmes finalités », selon un arrêt de la cour d’appel d’Aix–en–Provence²³. Ces références concurrentielles évoquant la nouveauté et l’activité inventive empruntent au droit des brevets. Celui-ci n’est pourtant pas applicable au droit d’auteur du logiciel.  

c. Le rejet jurisprudentiel du critère de nouveauté 

Dans un arrêt du 29 octobre 2024, la cour d’appel de Bordeaux a rappelé que « le logiciel n’a pas forcément à être nouveau mais sa conception doit procéder de choix arbitraires propres à l’auteur »²⁴. Dans sa décision, la cour va tout de même faire une comparaison avec les logiciels antérieurs en constatant que le logiciel dont la protection était revendiquée était « sans grande originalité, au contraire d’autres logiciels de comparaison »²⁵. À rebours de telles appréciations, réfutant le critère de la nouveauté et la comparaison avec l’état antérieur, la cour d’appel de Douai a énoncé, dans un arrêt du 8 février 2024, que « le caractère prétendument innovant ou nouveau du logiciel n’est pas en soi suffisant à caractériser la notion d’originalité »²⁶.

d. La nouveauté n’est pas suffisante pour caractériser l’originalité 

Dans le même sens, le tribunal judiciaire de Paris a exposé : « l’affirmation qu’il contient selon laquelle il n’existe pas d’autre programme d’imagerie automatique dans le monde est seulement relative à la nouveauté des fonctionnalités proposées, non à l’originalité revendiquée, notions distinctes l’une de l’autre »²⁷. Enfin, la cour d’appel de Paris a pu rappeler que « le critère de nouveauté était indifférent » pour caractériser l’originalité²⁸. S’il est tentant pour le praticien de faire un benchmark pour illustrer l’originalité, il doit donc garder à l’esprit que ce ne sera pas l’alpha et l’oméga de sa démonstration.  

2. L’investissement  

a. La tentation d’invoquer les moyens mobilisés 

Le demandeur peut être tenté d’invoquer les investissements humains et financiers pour la conception du programme. Ces éléments peuvent être prouvés par la production de factures, d’attestations, de fiches de paye, contrats de travail, bulletins de paie, lettres de missions, factures de prestations R&D, et tous documents comptables illustrant les dépenses intervenues dans le cadre de l’élaboration du logiciel.  

b. Un critère inopérant pour l’originalité 

Toutefois, ces éléments sont en principe inopérants pour démontrer l’originalité, contrairement au régime sui generis de la protection des bases de données, pour lequel l’investissement substantiel dans la constitution, la vérification ou la présentation de la base constitue un critère essentiel de protection²⁹. La jurisprudence a pu énoncer qu’était « inopérante l’argumentation […] relative aux moyens humains, financiers et de temps, nécessaires pour développer les logiciels, ces éléments, à les supposer établis, n’étant pas de nature à démontrer, à eux seuls, une quelconque originalité »³⁰.  

c. Une utilité limitée mais non négligeable 

Ainsi, bien que l’ampleur des investissements engagés ne puisse, à elle seule démontrer l’originalité du logiciel, elle n’est pour autant pas totalement dénuée d’intérêt. Ces éléments peuvent utilement être portés à la connaissance du juge, en particulier pour illustrer l’enjeu économique du litige, la réalité des efforts fournis ou encore l’existence d’un préjudice en cas de contrefaçon. Néanmoins, ces preuves ne doivent venir que conforter la démonstration fondée prioritairement sur l’originalité du logiciel. 

3. L’expertise non judiciaire

La dimension technique invite à la recherche d’un concours extérieur dans la figure de l’expert. Le caractère non contradictoire de cette expertise fragilise son utilisation. Le tribunal judiciaire de Paris, dans un jugement du 15 avril 2022 ³¹, n’a reconnu aucune force probante au rapport d’expertise produit. Elle considère que le rapport non contradictoire « ne lie aucunement le tribunal » mais également que l’appréciation de l’expert doit se faire sur « une question de fait requérant ses lumières » et non pas sur « une appréciation juridique qu’un expert n’a en principe pas à porter ». Pareillement, le juge a été amené, dans une autre affaire, à écarter une expertise non judiciaire pour des raisons méthodologiques car « les conclusions de l’expert, qui n’a pu se voir communiquer l’intégralité du code source, apparaissent d’une faible valeur probante », et qu’il y avait « un positionnement arbitraire du technicien afin de sélectionner [les éléments du code source] qu’il estimait pertinents »³². Il est alors tentant de privilégier l’expertise judiciaire. Toutefois, il est à craindre que le juge rejette une telle demande au motif qu’il ne lui appartient pas de suppléer la carence des parties dans la démonstration de la preuve. Ainsi, si l’expertise peut être sollicitée aux fins de caractériser une éventuelle contrefaçon, il paraît, en revanche, délicat de l’utiliser pour établir l’originalité de l’œuvre.  

 

 

À propos de l’auteur 

Gautier Kaufman est avocat au Barreau de Paris et spécialiste en droit de la propriété intellectuelle au sein du cabinet HLSK Avocats.