Quand le bon vieux classique consistant, pour un éditeur, à tenter d’entraver la concurrence en l’empêchant de sinterfacer avec ses logiciels se heurte à des parades tout autant techniques, que juridiques.
I – Quand l’arme de l’interopérabilité est utilisée par les éditeurs pour bloquer le développement de concurrents devenant trop gênants….
Les mauvais joueurs ont toujours existé. Parmi les éditeurs de logiciels, certains voient parfois d’un très mauvais œil l’émergence d’acteurs nouveaux dont ils craignent que la capacité d’innovation ne leur fasse de l’ombre. C’est particulièrement vrai dans l’ère actuelle du numérique, qui bouleverse tous les codes. Ainsi, lorsque ces nouveaux entrants cherchent à s’interfacer avec les produits existants sur le marché, le réflexe de ces éditeurs sera souvent de leur refuser toute connectivité avec leur technologie, afin de les isoler sur le marché et de se donner le temps de développer les fonctions nouvelles (le plus souvent web) proposées par ces nouveaux acteurs, en vue de les offrir in fine à leurs clients. Cette attitude est principalement le fait d’éditeurs « institutionnalisés », bien en place au sein d’une clientèle établie. De fait, ce type d’éditeurs ne supporte ni l’idée de voir des petits nouveaux proposer à leurs clients des logiciels susceptibles de communiquer avec les leurs, ni celle de ne pas avoir eu l’initiative de les développer avant. La réaction est alors, soit frontale, l’éditeur refusant purement et simplement de communiquer ses spécifications d’interfaces, soit plus oblique, c’est-à-dire que, sans exposer un refus catégorique, l’éditeur tarde à les fournir ou propose des prix tellement prohibitifs pour développer une interface entrante que cela équivaut à un refus de fait. Dans les deux cas, l’idée est la même : ii s’agit de bloquer son concurrent, de l’empêcher de déployer son nouveau produit sur le marché, de développer aussi vite que possible l’équivalent dans son offre logicielle, puis de retourner voir ses clients avec une offre enrichie en les convainquant qu’ils n’ont désormais plus besoin du nouvel entrant, le « tout en un » étant préférable à deux logiciels interconnectés.
II – … ces derniers ne sont pas dépourvus de moyens pour les contrer !
Le droit de la concurrence ouvre évidemment des possibilités intéressantes, puisque le refus d’assurer l’interopérabilité peut être assimilé à une pratique anti-concurrentielle, mais cette voie ne permet pas d’aller rapidement au but ; or l’on sait que, dans ce type de situation, le facteur temps est essentiel. Une autre possibilité est d’agir, dans le cadre d’une procédure judiciaire d’urgence, afin d’obtenir de l’éditeur récalcitrant, si possible sous astreinte, ses spécifications d’interfaces.
A côté de ces moyens judiciaires, il en existe d’autres, plus techniques. Ainsi au travers de ses articles L 122-6-1-III et IV, le Code de la propriété intellectuelle légitime les techniques de l’ingénierie inverse et de la décompilation d’un logiciel, dès lors que la finalité recherchée est bien celle de l’interopérabilité. La mise en oeuvre de ces droits essentiels est régulièrement validée par les juridictions. Récemment encore, un arrêt remarqué de la Cour d’appel de Caen du 18 mars 2015 a permis de refixer les limites entre l’autorisé et l’interdit en cette matière. En l’espèce, les conditions légales requises sont au nombre de trois : (i) que ces actes soient bien le fait d’un utilisateur légitime du logiciel (devant donc disposer d’une licence d’utilisation valide) ou du prestataire qu’il habilitera à cette fin, (ii) que les informations nécessaires à l’interopérabilité n’aient pas déjà été rendues facilement et rapidement accessibles[1] (il convient donc de les avoir préalablement demandées à l’éditeur et de s’être vu opposé un refus explicite, ou implicite, comme par exemple une demande de contrepartie financière excessive), le contrat de licence organisant parfois le modus operandi à cet égard, ce qu’il faut en tout premier lieu vérifier et (iii) que la décompilation ne porte que sur les parties du logiciel nécessaires à l’interopérabilité (critère difficile à apprécier et sur lequel les tribunaux ne se sont, à notre connaissance, jusqu’alors pas encore penchés). Une fois ces conditions réunies, la décompilation est juridiquement possible. Encore faut-il pour cela disposer des codes sources à décompiler, ce qui n’est pas une mince affaire. C’est sans doute la raison pour laquelle ces droits ne sont que rarement mis en oeuvre. La meilleure solution, face à ce type de difficulté, reste d’exiger judiciairement la communication forcée des spécifications d’interface devant le tribunal compétent, en invoquant le droit absolu à l’interopérabilité.
Pierre-Yves MARGNOUX
DERRIENNIC ASSOCIES
