Reverse engineering et Hadopi : du « concept » à la copie.

Les récents débats sur la loi Hadopi nous conduisent à nous interroger une nouvelle fois sur certaines pratiques du monde informatique. Examiner le produit du concurrent sous toutes les coutures pour en tirer tous les secrets et s’en servir pour doter sa propre innovation est inhérent à la nature humaine… La copie est sans doute le plus vieux métier du monde à l’exception cependant d’un autre…

Les tenants de l’intelligence économique demandent à leurs adeptes d’exercer une veille concurrentielle portant à la fois sur les concurrents et sur leurs produits. Benchmarker, un bel anglicisme promu au rang de néologisme par la magie des prosélytes de l’IE est devenu le mot d’ordre de certains d’entre eux. Mais, est-ce bien licite de vouloir décortiquer le produit d’un concurrent, un logiciel par exemple pour en tirer la substantifique moelle et s’en inspirer pour le développer. C’est ce que d’aucuns nomment la reverse engineering ou ingénierie à rebours. Alors comment définir cette dernière ; ce n’est pas de la copie ligne à ligne, c’est l’analyse du produit pour retrouver les idées et les concepts qui ont conduit à son fonctionnement et l’utilisation sans autorisation de ces idées. La reverse engineering c’est d’abord une affaire de concepts alors que la contrefaçon, au sens étroit du terme, est d’abord une affaire de copie. Avant de s’interroger sur la licéité de la reverse engineering, il convient donc de rappeler les neufs commandements de la protection des logiciels dont beaucoup sont issus de la directive européenne de 1991 sur la protection des logiciels (Directive 91/250/CEE du Conseil, du 14 mai 1991). Il faut avoir simultanément à l’esprit que le droit du logiciel va être confronté à un concurrent redoutable qui va lui faire perdre de son efficacité, voire lui faire mettre un genou à terre : le droit de la concurrence, en vertu duquel la protection d’un produit ne doit pas freiner la libre circulation des biens et/ou des services.

1.Les idées et les principes sont de libre circulation et ne sont pas protégeables, même si elles sont sous tendues dans la création d’un logiciel.

2.Pour être protégeable, un logiciel doit être marqué de la personnalité de son auteur.

3.Il n’est pas possible de recopier un programme que cela soit le code source ou le code objet, sauf accord du titulaire des droits et sous réserve du problème controversé des sauvegardes.

4.Lorsque l’on évoque la protection du logiciel, il faut avoir une vision globale et large.

5. Il n’est pas possible de copier la forme d’un programme qui serait original et non dictée par les fonctionnalités.

6.Les fonctionnalités ne sont pas protégeables (la jurisprudence a hésité, mais depuis 1995 semble avoir adopté définitivement cette solution) mais l’enchaînement des fonctionnalités est lui-même protégeable.

7.Il n’est pas possible de décompiler un logiciel sauf pour des raisons d’interopérabilité. Précisons à toutes fins utiles que la décompilation n’est qu’un sous-ensemble de la reverse engineering. En effet, la décompilation a pour but de retrouver le code source alors que l’objectif de la « reverse engineering » est de retrouver les principes de fonctionnement du logiciel. Malheureusement, de nombreux juristes confondent ces deux notions. L’interopérabilité est la possibilité de faire fonctionner deux logiciels complémentaires. En aucun cas, il ne s’agit de logiciels concurrents.

8.La décompilation est strictement encadrée par la loi : l’article L. 331-7 du code de la propriété intellectuelle précise que « Tout éditeur de logiciel, tout fabricant de système technique et tout exploitant de service peut, en cas de refus d’accès aux informations essentielles à l’interopérabilité, demander à l’Autorité de régulation des mesures techniques de garantir l’interoperabilité des systèmes et des services existants, dans le respect des droits des parties, et d’obtenir du titulaire des droits sur la mesure technique les informations essentielles à cette interopérabilité. Il faut donc que la personne voulant décompiler un logiciel s’adresse au préalable à la personne titulaire des droits sur cette application.

9. L’imitation n’est pas autorisée sur le fondement de la concurrence déloyale si les trois conditions suivantes sont remplies. La première condition est que les deux entreprises soient concurrentes. En seconde condition, il faut qu’il y ait eu des efforts » pour le développement du premier produit. Il faut enfin qu’il y ait usurpation un arrêt remarqué a donné une excellente définition de l’usurpation de l’effort intellectuel et des investissements d’un concurrent : il en va de fa sorte « lorsque, dans la réalisa­tion d’un objet, l’auteur, au lieu de donner libre cours à ses facultés créatrices, les met en sommeil et conduit un processus d’élaboration asservit à l’imitation de l’oeuvre d’autrui, cette démarche intellectuelle fournissant l’impulsion au travail créateur et lui servant de guide ».

Monsieur WALLON, Expert Judiciaire, n’hésite pas à définir de la manière suivante la méthode licite pour développer un programme concurrent et substituable à un autre.

1.« Le second logiciel doit avoir été développé sans aucune référence aux études techniques, analyses, examens des codes sources ou reverse engineering de la première application. Les seules données techniques communes peuvent être celles qui concernent les fonctionnalités.

2.Il est aussi indispensable que les développeurs ne soient pas ceux qui aient procédé à l’analyse du premier logiciel parce que, dans la pratique, il est impossible pour eux de développer la seconde application sans se référer ou sans exploiter les éléments techniques de la première.

Il est nécessaire que l’équipe chargée de la détermination des concepts et des idées du logiciel préexistant (cahier des charges) travaille indépendamment de l’équipe chargée de l’écriture du nouveau logiciel, sans avoir aucun contact et à l’aide d’une documentation honnêtement obtenue.

Ces mêmes règles étaient déjà’ retenues dans fa procédure de l’affaire Computer Associates contre Allai et dans l’affaire SYBEL contre BNP et al.

Bien qu’il s’agisse de disquettes ZIP, les mêmes principes sont rappelés dans l’affaire Iomega contre Nomai »

Ces mêmes principes sont également rappelés dans l’encyclopédie « wikipedia » à l’article « Clean Room Design ».

« Le Clean Room Design (aussi connu sous le nom de technique de la muraille de chine) est une methode consistant en la copie de plans par reverse engineering, puis en leur recréation sans pour autant porter atteinte aux droits de copyright et aux secrets de fabrication liés au plan original. Le Clean Room Design est utile pour éviter de porter atteinte aux copyrights et aux secrets de fabrication dans la mesure où il s’appuie sur une invention indépendante…

L’expression induit que l’équipe de conception travaille dans un environnement « propre », c’est-à-dire dont on peut démontrer qu’il est dénué de toute connaissance des techniques possédées et utilisées par le compétiteur. Par exemple, un Clean room design est effectué en faisant examiner par quelqu’un le système à mettre en place, puis en faisant écrire par cette même personne une notice détaillée. Cette notice est par la suite relue par un avocat pour s’assurer qu’il n’y est fait référence à aucun matériel copyrighté. Enfin, la notice sert à la mise en place du système par une autre équipe sans lien avec la première. »

Enfin, il convient de se demander comment est apprécié la reverse engineering fors de litiges. Le processus est en réalité le même que pour la contrefaçon. La reverse enginee­ring doit s’apprécier selon les seules identités. La question est de savoir si les identités sont le fait du hasard ou la marque d’une copie. il s’agit également de savoir si les différences sont le résultat d’une transformation ou d’un maquillage d’identités préexistantes ou si elles traduisent la personnalité de leur auteur.

Les juridictions doivent alors décider si les identités sont suffisantes pour conclure que l’auteur de l’oeuvre prétendument contrefaisante a été ou non développée à partir d’une copie de l’oeuvre originelle. En aucun cas, il ne s’agit de partir des différences sauf à démontrer qu’elles résul­tent d’un maquillage de l’oeuvre pré-existante. Par ailleurs, d’autres éléments peuvent être pris en compte. Par exemple, absence d’explications dans les lignes de code ou encore durée excessivement courte de développement de la seconde application…