L'originalité du logiciel : point de vue d'un technicien

La protection des logiciels est l'un des thèmes "phare" de ce congrès. Les textes juridiques, les articles de doctrine et les décisions de justice sont diverses et variées ; elles seront abondamment commentées par les intervenants.

En Europe et notamment en France l'"originalité" est l'une des conditions de la protection et les juridictions se tournent vers les experts judiciaires pour leur apporter tous éléments techniques et de fait leur permettant d'apprécier l'"originalité" d'un programme informatique. La jurisprudence du droit d'auteur distingue l'originalité, de la nouveauté et de la qualité. L'originalité traduit la personnalité de l'auteur et son empreinte dans la forme du programme. Mais, on peut se demander si les spécifications externes, le "look and feel" et l'exécution du programme ne manifestent pas aussi la personnalité de l'auteur.

Tel JANUS, le logiciel a deux faces. Celle visible par l'utilisateur au moment de l'exécution et, celle accessible au technicien : le code-objet résultant d'une transformation du code-source par un programme ad-hoc [1]. On notera, pour simplifier, qu'un code-source peut donner de nombreuses versions différentes du code-objet, mais qu'un code-objet ne peut résulter de la transformation que d'un seul code-source dont il est issu.

Jusqu'à présent la plupart des experts s'en tenaient exclusivement à l'examen des codes source et objet du programme pour répondre aux missions confiées par les juridictions sur l'originalité. Les principaux arguments avancés pour cette manière de procéder peuvent être résumés ainsi : un programme peut traduire la personnalité de son auteur même s'il n'est pas exécutable (routine, programme en cours d'écriture, etc..) et le code-source contient en lui-même l'ensemble des fonctionnalités qui seront divulguées lors de son exécution. L'exécution d'un programme peut se comparer à celle d'une ouvre musicale. Une bonne ou une mauvaise interprétation de l'ouvre est sans effet sur la forme concrétisée par la partition musicale.

Mais, la comparaison avec l'ouvre musicale est réductrice car ce qui la distingue du logiciel tient au fait que les fonctionnalités du programme sont sans relation directe avec la forme du code-source. Il est possible d'écrire un logiciel original dont l'exécution est strictement identique à celle d'un autre, développé indépendamment, et dont le code-source sera totalement différent ; c'est le cas des "clones". Certains experts, au demeurant peu nombreux en France, caractérisent l'originalité d'un logiciel par celle de leurs fonctionnalités [2]. Cette position est dangereuse et pourrait conduire à considérer comme sans originalité la quasi-totalité des progiciels à usage professionnel (traitement de textes, tableur, progiciels verticaux, etc..).

Les actions en contrefaçon reposent le plus souvent sur la comparaison de deux programmes : l'un dont la propriété et l'originalité sont revendiquées par le demandeur, l'autre prétendu contrefaisant. Dans la ligne du droit d'auteur, il est fréquemment demandé à l'expert de dénombrer et reproduire les éventuelles identités des lignes d'instructions des codes-source. Or, il faut souligner la possibilité pour un contrefacteur informaticien habile de transformer par des moyens automatiques ou semi-automatiques un code-source en un autre sans qu'aucune identité formelle puisse subsister entre l'original et la contrefaçon.

L'évolution des techniques de développement et l'apparition des méthodes orientées objet, le multimedia associant images graphiques et sons, sont autant de facteurs conduisant certains à étendre la notion de logiciel aux données exploitées. La directive européenne étend explicitement la protection aux documents formalisant les travaux précédant l'écriture du programme. On peut se demander si ce débat a lieu d'être en France dans la mesure où la loi du 3 juillet 1985 sur la protection des logiciels n'exclut pas l'application de la loi du 11 mars 1957 pour les autres éléments relevant de la propriété intellectuelle et artistique.

L'utilisation d'ateliers de génie logiciel et de certains L4G [3] atténue sensiblement l'empreinte de l'auteur dans l'écriture puisque les instructions sont générées automatiquement à partir d'une description des traitements, rigoureuse et contraignante. Il en est de même dans une moindre mesure des standards d'écriture propres à certaines entreprises. La notion juridique d'ouvre collective trouve ici à s'appliquer. Mais, il paraît difficile de soutenir qu'un programme développé avec un atelier de génie logiciel serait une ouvre dérivée des logiciels de l'atelier.

La plupart des procédures en contrefaçon de programmes informatiques achoppent sur le problème de l'antériorité. La partie revendiquant la propriété est fréquemment dans l'incapacité de prouver la date certaine de sa création. Les bons de commande, factures, bordereaux d'installation ne sont pas suffisants car ils ne sont que rarement associés au support d'enregistrement du programme revendiqué. Peu de tiers acceptent de témoigner ou d'attester dans les formes légales que le logiciel revendiqué est bien celui installé à telle date dans leur entreprise. En l'absence de date certaine de la revendication, un éventuel contrefacteur aura beau jeu de soutenir qu'il est la victime et que sa prétendue création a été copiée par son adversaire. Ces cas sont suffisamment fréquents pour être cités. Certains avocats se sont fait une spécialité de ce type de défense. Le dépôt d'un programme n'est pas obligatoire en France, mais il facilite les procédures judiciaires éventuelles.

Il convient que les experts judiciaires respectent une méthodologie rigoureuse et concilient respect du contradictoire et confidentialité des sources. On rappellera qu'il n'est pas interdit, en France, à l'expert d'opérer seul certaines investigations, à la condition de permettre aux parties d'en discuter contradictoirement avant le dépôt du rapport. Il n'a pas la possibilité d'entendre une partie hors la présence de l'autre. La solution, consistant à demander aux parties d'être assistées par un expert assermenté et d'entendre contradictoirement ces experts après engagement de confidentialité de leur part, n'est pas très satisfaisante.

La première étape de la méthode proposée consiste à figer la ou les formes de la revendication et celle du logiciel prétendu contrefaisant. Il convient d'obtenir pour l'un et pour l'autre le code-source et son code-objet. Les systèmes de développement (matériels et logiciels) de l'un et de l'autre doivent être remis à l'expert ou du moins l'ensemble des références permettant de se les procurer le cas échéant.

Les dates de création de l'un et de l'autre doivent être établies formellement. Sans preuve formelle de ces dates, l'expert doit revenir vers le Juge qui l'a commis pour savoir s'il doit poursuivre sa mission et ne pas encourir une réduction de la taxe de ses honoraires pour diligences inutiles. Il doit clairement exprimer dans son rapport, au besoin en rattachant cette information à un chef de mission de portée générale tel que "fournir tous éléments techniques et de fait de nature à permettre à la juridiction de se prononcer sur les responsabilités encourues", un avis sur l'antériorité des logiciels soumis à son expertise.

La deuxième étape doit permettre de vérifier les liens directs entre les codes-source et les codes-objet. On prendra soin de vérifier avec les utilitaires appropriés si les codes-objet ont été compactés et/ou cryptés. La lecture des mémoires mortes (roms, eproms, etc..) impose de prendre des précautions particulières car les systèmes de lecture ajoutent parfois aux caractères lus des données standard de mises en forme. Ces données se retrouvent quels que soient les objets lus et il importe de ne pas les confondre avec le code lui-même. Ces opérations doivent être réalisées par l'expert, avec son propre matériel, ou par un laboratoire choisi par lui et sous son contrôle et non par les parties comme c'est souvent le cas si l'expert atteint la limite de ses compétences techniques.

On interrogera ensuite les parties contradictoirement sur le processus de développement et les caractéristiques propres de leur logiciel (ouvrages et travaux de référence, solution technique retenue [4], erreurs commises volontairement, marqueurs particuliers [5] ou clés cryptées [6], etc..). Les réponses de la partie en défense seront enregistrées avant celles du demandeur. Cette phase d'enquête est importante dans le cas où l'un des logiciels résulterait d'un maquillage délibéré de l'original.

La comparaison proprement dite commencera par celle des codes-objet pour rechercher les marqueurs et/ou les clés cryptées et vérifier s'il y a ou non copie servile. A l'aide d'un logiciel approprié, on comptera et identifiera les suites identiques de sept à dix caractères ; ces caractères seront traduits en instructions "assembleur". La liste obtenue sera soumise aux parties pour observations éventuelles.

Au cours de la cinquième étape l'expert recherchera dans les programmes-source les particularités signalées par les parties au cours de la phase d'enquête avec un logiciel approprié. Il vérifiera les dates des fichiers et celles pouvant figurer dans les programmes ; il contrôlera visuellement le code ou avec un correcteur orthographique pour repérer d'éventuelles fautes d'orthographe dans les commentaires qui pourraient se retrouver au même emplacement dans les deux programmes. Les identités significatives seront communiquées aux parties pour explication éventuelle. Si l'expert n'est pas convaincu par les explications fourniers, il reprendra la phase d'enquête et recommencera les comparaisons. Ce processus est renouvelé autant de fois que nécessaire.

A l'issue de ces investigations l'expert devrait être capable de conclure s'il y a eu ou non copie servile, emprunt partiel ou développement dans des conditions anormales ou contraires aux règles de l'art. Il lui restera à rédiger son rapport en s'abstenant de toute appréciation d'ordre juridique. Mais, rien ne lui interdit d'attribuer davantage d'importance à telle ou telle question posée à la condition de s'en expliquer clairement. Il faut éviter que le Juge puisse se faire une idée inexacte de la réalité technique et de l'avis de l'expert, à partir de réponses à des questions figurant dans la mission mais sans intérêt sur le plan de la contrefaçon. Dans l'hypothèse ou peu d'instructions sont communes entre les programmes à comparer, mais où certains marqueurs sont visibles et les quelques identités relevées ne peuvent être le fruit du hasard, l'expert devra reconstituer la manière dont la copie a été obtenue à partir de l'original. Il arrive parfois qu'"original" et "copie" soient issus d'un programme commun dont l'auteur n'est pas dans la cause ou d'emprunts à des logiciels du domaine public.

L'annexe A récapitule la démarche à suivre.

Nous avons choisi quatre exemples pour l'illustrer. Ces cas ont été volontairement simplifiés et transformés à des fins didactiques.

Le premier cas peut se résumer ainsi MM. X et Y ont participé au sein de la société A à la conception et la réalisation d'une carte multimodem. Ils décident de quitter la société A pour créer leur propre entreprise, la société B. Dès la création de B MM. X et Y réalisent une carte concurrente de celle de A et la commercialisent. A poursuit B et MM. X et Y en contrefaçon.

L'expertise technique porte à la fois sur la partie électronique des cartes A et B et sur les programmes enregistrés en mémoire morte. L'expert conclut que la partie électronique des cartes est différente bien que les composants utilisés soient similaires et compatibles.

Le problème de l'antériorité ne se pose pas ici car nul ne conteste que la carte B est postérieure à la carte A.

L'expert obtient des parties les sources en assembleur des logiciels litigieux. Les parties s'opposent à ce que les programmes-source soient soumis au débat contradictoire. L'expert désigné par le Tribunal propose alors aux parties que les experts-privés de chacune d'elles participent à ses investigations contre l'engagement de garder confidentielles les informations obtenues à cette occasion. Le Conseil de la société A soutient qu'un tel engagement ne serait pas valable car les experts-privés sont mandataires des parties et ils doivent rendre compte complètement de leur mission.

Au cours de la phase d'enquête, l'expert pose la question à MM. X et Y de savoir s'ils ont ou non copiés tout ou partie du source de A. Leur réponse est formelle : ils ont développé le logiciel de B ex-nihilo à partir de leur seul savoir-faire.

L'expert constate après une première comparaison un certain nombre d'identités qu'il n'attribue pas au hasard ou à la mémoire fût-elle excellente de MM. X et Y. Il livre quelques identités à la réflexion des parties.

MM. X et Y soutiennent que les identités révélées ne sont que l'expression de leur personnalité. Il n'est pas anormal, selon eux, que de telles identités soient trouvées.

L'expert propose alors à MM. X et Y d'écrire de mémoire une des routines des logiciels litigieux en leur fournissant les spécifications et l'algorithme. MM. X et Y s'y refusent en considérant comme dégradante la manière de procéder de l'expert.

Celui-ci procède alors à une deuxième comparaison et constate que certains commentaires [7] sont écrits dans chaque programme tantôt correctement, tantôt avec des fautes d'orthographe. Les fautes d'orthographes se situent aux mêmes endroits dans les routines. Il soumet une nouvelle fois ses constatations aux parties. MM. X et Y s'opposent avec vigueur à cette manière itérative de procéder et demande à l'expert de s'en tenir strictement aux termes de sa mission : faire l'inventaire des identités et des différences, calculer un ratio et présenter aux parties le résultat de ses travaux en une seule fois. L'expert se tourne alors vers le juge qui l'a commis. Il soutient qu'inventorier l'ensemble des identités et des différences revient à divulguer les programmes-source considérés comme confidentiels par les parties. Le volume des instructions à comparer nécessiterait des moyens techniques sans rapport avec l'intérêt du litige et cela n'apporterait rien sur le plan technique car un programme peut n'avoir aucune instruction commune avec un autre et résulter de sa transformation par des moyens automatiques sans apport créatif. Le magistrat confirme la position exprimée par l'expert.

L'expert conclut ainsi son rapport : "Si, en l'état, le technicien peut retenir un pourcentage d'identités proche de 60 %, il faut comprendre que ces 60% n'ont pu être obtenus qu'à partir d'une copie servile à 100%. Au fur et à mesure du temps, la société B et MM. X et Y ont été conduits à améliorer leur programme et à le modifier pour corriger d'éventuelles erreurs qui subsisteraient ou pour améliorer leur produit et le rendre plus concurrentiel. Ces modifications successives tendent à faire baisser le taux d'identités mais le point de départ de ce développement est bien une copie servile à 100%, sans laquelle le programme n'aurait pas pu être développé sous cette forme.

Aucun élément de conception, ni le fait que les programmes aient été développés par le même auteur ne peuvent expliquer de pareilles identités de fait.

On doit conclure, sur le plan technique, que les programmes B ont été conçus et réalisés à partir d'une copie de ceux revendiqués par A... Selon toute vraisemblance, B, MM. X et Y ont procédé ainsi :

1) Assemblage du programme de A pour connaître la liste des symboles (identificateurs).

2) Création sur papier de la table de correspondance des symboles.

3) Remplacement avec un éditeur de textes des mnémoniques n'ayant pas leur équivalent dans l'assembleur choisi.

4) Remplacement avec un éditeur de textes des symboles par les nouveaux selon la table définie à l'étape 2.

5) Révision pas à pas, avec l'éditeur de textes, du programme obtenu en cadrant les commentaires et en éliminant les lignes d'étoiles et les lignes blanches.

6) Ultérieurement, modification, simplification et optimisation du programme obtenu en fonction du résultat des tests de fonctionnement de la carte."

Le deuxième cas oppose la société A implantée dans plusieurs pays à la société B distributeur français d'un progiciel propriété d'une société C de droit américain. A accuse B d'avoir contrefait son programme et mène à cet effet des actions en contrefaçon dans la plupart des pays où le logiciel de C est distribué.

Lors du premier rendez-vous d'expertise, la société B expose qu'elle ne dispose pas de sources du progiciel de C dont elle n'est que le distributeur.

C soutient qu'à l'occasion de la procédure américaine le juge a ordonné que l'accès aux sources des programmes soit à usage exclusif des experts américains. Elle reconnaît qu'une précédente version de son programme a contrefait le programme de A. Mais, un accord est intervenu et la nouvelle version commercialisée n'est plus une contrefaçon du programme de A car toutes les instructions identiques ont été remplacées par d'autres. Il convient se surseoir à l'expertise tant que le juge américain n'a pas rendu sa décision (litispendance internationale).

L'expert retourne alors vers le magistrat pour faire trancher les questions de droit. Le magistrat ordonne la production des sources sous forte astreinte et considère qu'il n'y a pas lieu d'attendre la décision du juge américain car les règles de droit applicables en France ne sont pas les mêmes que celles applicables aux Etats-Unis.

C persiste dans son refus de remettre les sources et l'expert dépose un rapport en l'état à partir des rapports des experts américains (experts des parties et expert nommé par le juge) qui, eux, ont eu connaissance des sources.

Il apparaît que l'architecture des programmes est la même, que la nouvelle version a été développée à partir de la précédente (reconnue contrefaisante) par les développeurs l'ayant réalisée.

L'expert ne peut se prononcer formellement en l'absence des sources. Il relève cependant que :

Le fait que les développeurs soient les mêmes pour les deux versions est contraire aux règles de l'art. Il convenait de repartir des seules fonctionnalités et de développer en "clean room", sans référence au source de la version précédente et avec des programmeurs n'ayant pas participé au développement de la première version.

L'architecture identique des deux versions montre que la deuxième version a été obtenue à partir de la première en transformant, sans apport créatif, les instructions identiques. Cette méthode s'apparente davantage à un maquillage qu'à un travail original portant l'empreinte de la personnalité de son auteur.

On apprendra depuis que la cour d'appel américaine a considéré que l'architecture n'est pas protégeable en tant que telle et que la contrefaçon n'est pas établie car il n'y a plus une ligne d'instructions identiques entre le programme de A et celui de C.

Il n'est pas certain que la décision soit la même en France, -avant même l'application de la directive européenne protégeant explicitement les travaux préparatoires, dont l'architecture si elle est formalisée-, car la transformation par des moyens manuels ou automatiques, sans apport créatif, d'un programme en un autre qui aurait une forme différente n'est pas de nature à faire échec à la protection.

Le troisième cas relate une action en contrefaçon qui a mal tourné, faute d'une méthode d'expertise rigoureuse et du manque de compétence de l'expert, en programmation "Assembleur".

Les sociétés A et B commercialisent des imprimantes de péri-télématique directement concurrentes.

Après avoir fait saisir, dès le début de la commercialisation, le logiciel de B, A poursuit B en contrefaçon au motif que le logiciel intégré en mémoire morte est une contrefaçon de son propre développement. Elle appuie sa thèse sur le fait que le numéro de sécurité social de son directeur technique se retrouve dans la mémoire morte de l'imprimante fabriquée par B.

L'expert ne vérifie pas l'antériorité et commence ses opérations. Il demande à A de procéder avec ses moyens techniques à la lecture de sa mémoire morte et de celle de son adversaire, car lui-même ne dispose pas du matériel nécessaire.

B conteste cette manière de procéder car l'expert n'a pas les moyens de s'assurer que les caractères lus dans la PROM [8] sont bien ceux listés sur papier. Le dispositif "intelligent" de lecture pourrait permettre en effet de transformer par programme les octets lus.

B soutient que le contenu de la PROM peut être réparti en deux zones : celle contenant les instructions du programme et celle contenant les données. Les données sont des chaînes et des dessins de caractères normalisés (VIDEOTEX) dont ni B ni A ne peuvent revendiquer la propriété. Le numéro de sécurité sociale se trouve dans cette zone non susceptible de protection qu'elle ne nie pas avoir copiée.

Faute de date certaine, en l'absence de dépôt, A est dans l'incapacité de prouver formellement l'antériorité de son programme. En effet, ces matériels sont destinés au grand public et distribués par des chaînes de magasin dont aucun ne peut certifier que le logiciel revendiqué était bien enregistré à une date donnée dans la PROM de l'imprimante de A. De fait, la seule date certaine est celle du logiciel de B puisqu'il a fait l'objet d'une saisie.

L'expertise est alors dans une impasse et l'expert est contraint de déposer un rapport en l'état.

Le dernier cas est une affaire pénale antérieure à l'application de la loi du 3 juillet 1985 sur la protection du logiciel. La loi applicable est celle du 13 mars 1957 sur la propriété littéraire et artistique.

MM. X et Y, salariés de l'entreprise A dont ils sont les seuls informaticiens développent un progiciel vertical. Ils quittent ensuite cette entreprise pour créer la leur. Ils distribuent et installent sans l'accord de A le logiciel élaboré dans cette entreprise.

MM. X et Y soutiennent devant le Tribunal correctionnel que le logiciel est leur propriété car ils étaient les seuls informaticiens de l'entreprise A.

Le gérant de A, partie civile, soutient que, bien que non-technicien, le logiciel a pu voir le jour grâce aux concepts qu'il a développés antérieurement à l'arrivée de MM. X et Y dans son entreprise et aux instructions qu'il leur a données.

L'expert est désigné par le Tribunal Correctionnel. Il lui est demandé de dire si existait un début de logiciel avant l'entrée de MM. X et Y dans l'entreprise A et si la part de chacun des auteurs peut être distinguée dans le programme litigieux.

L'entreprise A présente au cours des opérations d'expertise des listages datés, antérieurs à l'arrivée des prévenus dans l'entreprise. S'agissant d'une affaire pénale, l'expert n'exclut pas la possibilité qu'ils aient pu être antidatés. Faute de dépôt des sources chez un tiers, il proposera au tribunal de considérer ces pièces comme non probantes.

L'expert retrace ensuite le processus d'élaboration du programme. Il relève que les standards de programmation appliqués par MM. X et Y, la participation active au cours de l'analyse et des tests du gérant de A ne lui permettent pas de déterminer la part précise de chacun dans le résultat final matérialisé par le source du programme définitif.

François WALLON

Vice-Président de l'ADIJ

Vice-Président de la Compagnie nationale des experts judiciaires en informatique

Expert en informatique et bureautique près la Cour d'Appel et le Tribunal Administratif de Paris

[2]Spécifications externes.

[3]Langage de quatrième génération.

[4]Notamment l'architecture. La question de la protection de l'architecture reste discutée. Mais le fait que les programmes à comparer aient la même architecture est un indice d'une copie possible.

[5]e.g. Faute d'orthographe.

[6]e.g. Date de naissance ou numéro de sécurité sociale de l'auteur.

[7]Le commentaire est une phrase écrite, en l'espèce en français, par le programmeur pour expliquer telle ou telle instruction ou solution technique choisie par lui.

[8]Programmable Read Only Memory : mémoire morte.