© treenabeena - Fotolia.com
Si vous n’avez rien compris au titre de cet article c’est que vous n’êtes point juriste ! Mais non je plaisante voyons… Même les plus juristes n’ont rien compris je suis sûr. D’ailleurs je crois que je suis le seul à le comprendre ce titre. Je l’ai d’ailleurs écrit avant de l’avoir compris, c’est vous dire mon état mental. Coup de chance cependant, cela semble coller avec l’apport de l’arrêt de Cour de cassation (chambre civile 1er du 20 octobre 2011 N° de pourvoi: 10-14069) qui m’intéresse.
Il faut vous dire messieurs dames que la question de l’interopérabilité du logiciel n’a jamais été abordée à ce niveau de nos juridictions, à ma connaissance. Pourtant la notion d’interopérabilité est présente dans le Code de la propriété intellectuelle (CPI) depuis la création du statut propre au logiciel (article L.122-6-1 IV) et la transposition de la directive associée en 1994. Avouons que l’on ne sait pas exactement comment interpréter ce terme depuis. On sait bien pourtant quelle belle idée soutient cette notion : le logiciel doit pouvoir communiquer avec un autre logiciel. Cela est un facteur dynamisant pour l’économie puisqu’il facilite la concurrence en évitant la création de systèmes fermés rendant les utilisateurs captifs (oui je sais que certains doivent se reconnaître dans ces mots).
Une belle idée de départ donc mais mal desservie par un texte mal ficelé dans le CPI. En effet le principe a pris du plomb dans l’aile sous les coups de boutoir des intérêts économiques. Le résultat en est qu’il n’affirme pas l’obligation pour les éditeurs de rendre leur logiciel interopérable (voyez les logiciels libres / open source pour cela). Non, le texte adopte la solution par défaut, celle du perdant. Du principe éthéré il ne reste plus qu’une exception difforme et honteuse au droit supérieur qu’a l’auteur de protéger son logiciel en l’état compilé.
De l’avis de la doctrine, le résultat que l’on appelle l’exception de décompilation est une fausse exception car le principe est en fait celui de la non autorisation de décompiler. En effet, les conditions entourant le droit qu’a un utilisateur (légitime) d’un logiciel de décompiler sont particulièrement restrictives, cherchant un équilibre certainement inatteignable entre la volonté d’offrir la possibilité de rendre interopérable un logiciel qui ne le serait pas par nature d’une part, et d’autre part l’obligation de protéger le secret qui entoure la conception du logiciel. Equilibre inatteignable et inutile à mon sens car nul n’était besoin de protéger le secret de conception dans un dispositif qui affirmait déjà la protection du logiciel par le droit d’auteur en tant qu’oeuvre. L’étude d’un logiciel pour en comprendre le fonctionnement est une chose pour moi naturelle qui ne devrait entraîner aucune forme de violation d’un droit de propriété intellectuelle pour autant que l’analyste se contente de tenter d’étudier et ne reproduise pas la forme de ce logiciel mais tout au contraire l’améliore. On m’a enseigné que le but de brevet était d’encourager la divulgation d’innovations qui sinon demeureraient secrètes et ne rentreraient pas dans l’état de l’art. Que penser alors de cet étrange volonté de protéger une oeuvre logicielle qui par ailleurs continue d’entretenir un secret au travers de la technique de la compilation, technique elle-même protégée par la loi ?
Aussi incongrue que j’ai toujours trouvé ce dispositif, il n’en demeure pas moins que tout utilisateur souhaitant étudier le fonctionnement d’un logiciel qui ne serait pas en « open source » (source code lisible) doit s’inquiéter de ce que cette décompilation ou ingénierie inverse réponde bien à une seule et unique finalité : l’interopérabilité du logiciel avec un autre. L’objectif doit donc être de permettre à un utilisateur de faire dialoguer deux programmes qui n’ont pas été conçus pour dialoguer. Voilà ce qu’est depuis toujours l’interopérabilité pour les juristes ayant à composer avec ce texte.
La jurisprudence citée en référence évoque un cas de décompilation réalisée aux fins de pouvoir rendre le format de données d’un logiciel A compatibles avec le fonctionnement d’un logiciel B. Jusque là rien de nouveau puisque ce cas semble bien entrer dans la notion d’interopérabilité. Cependant cette compatibilité de format était en fait réalisée en vue de pouvoir exporter une fois pour toute les données du logiciel A vers le logiciel B, ce dernier ayant vocation à se substituer au premier. Le prestataire en charge de l’opération était bien entendu aussi l’éditeur du Logiciel B. Autant dire que les logiciels n’allaient en fait jamais communiquer ensemble. La question posée aux magistrats était alors de déterminer si la notion d’interopérabilité concerne un tel cas où le but est uniquement de permettre une opération de migration autrement appelée parfois du terme de « moulinette » dont vous remarquerez l’improbable et surprenante technicité.
La réponse donnée par les magistrats est affirmative. Ainsi si une opération de migration de données implique de devoir étudier le fonctionnement d’un logiciel afin de réaliser une exportation des données dans un format réexploitable, cette opération rentrera dans le champ de l’interopérabilité. Pour conclure, remarquons que ce cas de figure ne concerne à mon sens que des formats de données propriétaires souvent cryptées qui ne peuvent être uniquement extraits d’une base de données. La plupart du temps la migration ne posera pas de problème d’accès aux données mais demandera effectivement un travail de reformatage des données.
Enfin une question me tarabuste car pour que l’exception de courte citation puisse jouer, il est nécessaire que l’utilisateur ait demandé à la société éditrice du logiciel de lui fournir les informations nécessaires à l’interopérabilité. Il faut donc supposer que ce point avait fait l’objet d’une étude en Appel et que la preuve avait été faite que la société éditrice (FIDUCIAL INFORMATIQUE pour ne pas la nommer…) avait répondu par la négative à la demande de transmission d’information.
La question de l’interopérabilité est donc désormais un tout petit plus claire mais le chemin est encore long vers l’idéal que devrait être l’expression de ce principe essentielle pour la pérennité de la société de l’information et sa liberté.
Ah oui le titre ! Et bien finalement la réponse est positive et cela un sens il me semble puisque la question de l’interopérabilité du logiciel B avec le logiciel A n’a de sens juridiquement qu’à partir du moment ou le logiciel A n’est pas interopérable avec le logiciel B par nature. Dès lors là où s’arrête l’interopérabilité du logiciel A, là seulement commence à naître le besoin d’interopérabilité du logiciel B. Mais ce néoadage cyberjuridique est d’autant plus justifié dans notre cas que ce besoin d’interopérabilité était à sens unique. C’est bien le fait que ce besoin d’un format commun ne soit pas partagé par les deux logiciels qui a suscité cette problématique d’interopérabilité autrement normalement appelée compatibilité…
Gérald SADDE – Avocat un peu tourmenté parfois…
