Contrefaçon de logiciel : preuve et sanctions

Une similitude de fonctions ou de résultats ne suffit pas à établir la contrefaçon d’un logiciel. L’analyse doit identifier les éléments originaux protégés, vérifier la titularité et comparer les expressions effectivement reprises.

La question centrale n’est donc pas seulement de constater que deux produits accomplissent des tâches proches. Il faut déterminer si la ressemblance alléguée concerne une forme d’expression protégée et si elle correspond à l’un des actes réservés au titulaire par le Code de la propriété intellectuelle.

Déterminer ce que le droit d’auteur protège

L’article L. 122-6 réserve notamment à l’auteur du logiciel la reproduction, l’adaptation et la mise sur le marché dans les conditions qu’il définit. Le matériel de conception préparatoire peut également entrer dans le champ de la protection applicable au logiciel.

La Cour de justice de l’Union européenne, dans l’arrêt SAS Institute (C-406/10), a jugé que la fonctionnalité d’un programme, le langage de programmation et le format de fichiers de données utilisés pour exploiter certaines fonctions ne constituent pas, en tant que tels, une forme d’expression protégée par le droit d’auteur sur le programme.

Cette distinction délimite l’objet du débat. Décrire une fonction, un résultat attendu, un langage ou un format ne suffit pas à désigner une expression protégée. L’allégation doit porter sur un élément susceptible de relever de la protection du logiciel, sans transformer la fonction elle-même en objet d’exclusivité.

Grille d’analyse pratique

La lecture du dossier peut être organisée autour des catégories établies par ces textes et par l’arrêt SAS Institute : l’élément invoqué est-il une fonctionnalité, un langage ou un format exclu de la protection en tant que tel, ou une expression du programme ? L’acte reproché relève-t-il de la reproduction, de l’adaptation ou de la mise sur le marché visées à l’article L. 122-6 ?

Cette grille ne remplace pas l’examen des faits. Elle permet de présenter séparément l’objet revendiqué et l’acte reproché, deux questions nécessaires pour appliquer les dispositions relatives au logiciel.

Vérifier la titularité et les licences

Le demandeur doit pouvoir rattacher le logiciel invoqué aux droits qu’il entend exercer. Les contrats de travail ou de prestation, les cessions, les contributions et les versions publiées peuvent éclairer cette question selon la situation du projet.

Il convient aussi de distinguer le code revendiqué des bibliothèques open source, des composants commerciaux et des éléments provenant de tiers. Cette distinction évite d’attribuer au titulaire des éléments dont le régime dépend d’une licence ou de droits appartenant à une autre personne.

Séparer les trois questions du dossier

1. Qui détient les droits ? Identifiez le logiciel et la version au titre desquels les droits sont invoqués.
2. Quel est l’objet protégé ? Distinguez l’expression du programme des fonctionnalités, langages et formats non protégés en tant que tels.
3. Quel acte est reproché ? Rattachez l’allégation à la reproduction, à l’adaptation ou à la mise sur le marché visées par l’article L. 122-6.

Cette séparation reprend les éléments juridiques que les sources permettent d’établir. Elle évite de présenter une simple proximité fonctionnelle comme la démonstration complète d’une violation des droits sur le logiciel.

Préserver les versions et traces

Les versions du logiciel, les contrats et les éléments datés disponibles peuvent être conservés afin de décrire précisément le logiciel invoqué et la chronologie présentée. Une date ne démontre toutefois pas, à elle seule, qu’une fonctionnalité devient une forme d’expression protégée ni qu’un acte réservé a été accompli.

Le guide consacré au dépôt de logiciel et à l’horodatage présente les outils de dépôt et de datation. Dans le présent article, ces éléments servent uniquement à identifier les versions et la chronologie, sans leur attribuer une portée probatoire que les sources listées n’établissent pas.

Tenir un registre de preuve (méthodologie)

Un inventaire interne peut associer chaque pièce à la version ou au contrat qu’elle décrit. Il s’agit d’un classement documentaire, non d’une règle légale de preuve ni d’une garantie quant à l’issue d’un litige. L’inventaire peut reprendre des informations factuelles simples : intitulé, date, version concernée et emplacement de conservation.

Comparer avec une méthode reproductible

La comparaison doit rester centrée sur la distinction posée par l’arrêt SAS Institute. Une correspondance limitée à la fonctionnalité, au langage de programmation ou au format de fichiers ne caractérise pas, en tant que telle, la reprise d’une forme d’expression du programme.

Pour replacer cette distinction dans le cadre général de la protection, consultez les mécanismes de protection d’un logiciel. La présentation peut ensuite rapprocher les éléments précisément invoqués des actes énumérés par l’article L. 122-6, sans déduire automatiquement une contrefaçon d’un score de similarité ou d’une ressemblance de résultat.

Choisir la réponse adaptée

L’analyse réunit le droit invoqué, l’objet prétendument protégé et l’acte reproché. Les articles L. 335-3 et L. 335-2 permettent ensuite d’exposer la qualification de délit et les peines pénales prévues par le Code.

Sanctions pénales prévues par le Code

L’article L. 335-3 qualifie notamment de délit la violation des droits de l’auteur d’un logiciel définis à l’article L. 122-6. L’article L. 335-2 prévoit trois ans d’emprisonnement et 300 000 euros d’amende, peines portées à sept ans et 750 000 euros lorsque les délits sont commis en bande organisée.

Ces dispositions établissent la qualification pénale et les peines mentionnées. Le présent développement reste limité à leur contenu et n’ajoute aucune procédure ou sanction absente des sources réunies.

Pour préparer l’analyse des éléments protégés et des actes allégués, consultez notre service de défense contre la contrefaçon de logiciel.