Peut-on décompiler un logiciel ? Quels enseignements récents de la jurisprudence communautaire ?

Afin de cerner le procédé de décompilation d’un logiciel et les conditions légales qui subordonnent sa mise en œuvre, il nous faut tout d’abord étudier la composition d’un programme d’ordinateur. Celui-ci se structure autour de deux codes : le code source, écrit en un langage intelligible par un être humain définissant les fonctionnalités prévues par son auteur ; le code objet, écrit en un langage informatique de programmation compréhensible par la machine qui l’exécute.

L’étape de traduction du code source au code objet est dénommée la « compilation », le chemin inverse la « décompilation ». Cette technique également appelée « rétro-ingénierie » (ou reverse engineering¹) consiste à désassembler un objet pour en déterminer le fonctionnement.

La protection du logiciel par le Droit de la propriété intellectuelle est un sujet de longue date. Depuis 1991, le programme dans son ensemble, ainsi que ses travaux préparatoires, peuvent faire l’objet d’une protection par le droit d’auteur s’ils en remplissent les conditions².

Par principe, l’opération de décompilation informatique ne peut être effectuée qu’après autorisation de l’auteur ou de l’ayant droit³. Ce qui est justifié par la nécessité de protéger la création. En effet, une fois le code source obtenu par un tiers, la reproduction du programme (et donc sa contrefaçon) est d’autant plus aisée.

En dehors de ce cas, la législation prévoit, en tant que dérogation au monopole d’exploitation de l’auteur, l’exception de décompilation⁴.

Au sens de l’article 9.2 de la convention de Berne, toute exception doit d’abord être soumise au « triple test »⁵ : limitation à certains cas spéciaux ; obligation de ne pas porter atteinte à l’exploitation normale de l’objet protégé ; obligation de ne pas causer de préjudice injustifié aux ayants droit.

Le  juge peut alors refuser le bénéfice d’une exception à l’utilisateur d’une œuvre quand bien même les conditions « internes » seraient remplies⁶.

Ensuite, loin de la souplesse américaine posée en la matière par les arrêts Atari et Sega⁷, le législateur européen circonscrit l’exercice de l’exception de décompilation à une double série de conditions cumulatives⁸.

En premier lieu, elle ne peut être exercée que par un utilisateur légitime (cessionnaire, licencié…), pour obtenir des informations non spontanément fournies par l’auteur, et dans la limite de la partie du programme nécessaire à assurer son interopérabilité, c’est-à-dire à permettre son fonctionnement ou sa communication avec d’autres programmes⁹. Cette limite tient au fait que le logiciel, à la différence des autres œuvres, ne peut vivre en autarcie. Il doit donc pouvoir être adapté aux interfaces permettant son utilisation.

En second lieu, les informations obtenues ne peuvent être utilisées qu’aux fins d’organiser l’interopérabilité, elles ne peuvent être communiquées à des tiers non concernés par ce processus¹⁰, et ne peuvent être réutilisées pour créer un nouveau programme.

Il fallait alors comprendre que toute décompilation d’un programme réalisée dans un but étranger à celui d’assurer son interopérabilité était proscrite.

Bien que nous ne disposions que d’un maigre corpus de décisions, les juridictions françaises ont toujours appliqué le donné légal de manière stricte. La Cour d’appel de Paris, le 21 février 2006, a jugé que la décompilation en vue d’étudier la sécurité du logiciel était interdite¹¹. De son côté, la Cour d’appel de Caen, le 28 octobre 2010, a sanctionné un acte de maintenance corrective¹².

Pourtant, la Cour de justice de l’Union européenne s’est récemment prononcée sur une affaire relative à la décompilation¹³, élevant davantage l’amoncellement des conditions. D’après les juges européens, l’article 5, § 1, de la Directive 91/250/CEE du 14 mai 1991 permet à tout acquéreur légitime d’un programme de le décompiler pour en corriger les erreurs à l’origine de son dysfonctionnement.

Ils ajoutent que cette technique n’est permise que si elle est nécessaire à un usage conforme à sa destination. D’après les conclusions de l’avocat général, la destination d’un programme doit être entendue comme les fonctionnalités prévues par son auteur¹⁴. Ainsi, modifier un programme au-delà de ces défauts (en améliorant ses fonctions par exemple) est prohibé.

La Cour juxtapose ainsi à la condition légale d’un acte nécessaire à assurer l’interopérabilité du logiciel, la condition d’un acte nécessaire à la correction d’une erreur empêchant son fonctionnement, sans pour autant définir la notion d’erreur.

Afin de prévenir toute insécurité, les juges ont précisé que la décompilation pouvait être aménagée contractuellement. Il est en effet dans l’intérêt de l’auteur du programme de limiter autant que possible cette opération pour éviter tout risque de contrefaçon.

Pour ce faire, il peut insérer une clause par laquelle il contrôlera lui-même le respect des conditions légales, ou encore une clause se réservant le droit de corriger les erreurs via une prestation de maintenance.

La rétro-ingénierie informatique étant autorisée qu’en cas de lacunes informationnelles, l’auteur devra privilégier l’information préalable de l’utilisateur, en déposant par exemple toutes les informations nécessaires à l’interopérabilité chez un tiers (un notaire ou encore à l’Agence de protection des programmes).