Analyse juridique de la brevetabilité logicielle

Pourquoi la question des brevets logiciels est mal posée

Les partisans de la brevetabilité logicielle justifient celle-ci par
la nécessité de protéger la partie logicielle qui est de plus en plus
présente au sein des biens matériels innovants, et pour laquelle le
régime du doit d’auteur n’offre pas selon eux de protection suffisante.

Un exemple couramment abordé par les membres des offices de brevets
est celui d’une machine à laver nouvelle, en ce qu’elle lave mieux le
linge, le programme de lavage innovant étant mis en oeuvre au moyen
d’un ordinateur. Le logiciel exécuté par cet ordinateur serait donc,
dans ce cadre, à l’origine de la contribution technique apportée par
cette nouvelle machine, et devrait donc être couvert par les
revendications du brevet.

Ce cas d’école sert de base conceptuelle pour postuler l’existence de
logiciels « techniques », par opposition aux
logiciels « en tant que tels », qui ne seraient,
eux, pas brevetables, car ne produisant pas de contribution technique.

Cependant, le postulat de l’existence d’une discrimination possible
entre logiciels « techniques » et
« non techniques », basée sur l’examen de leurs
effets, que nous appellerons la « doctrine de la technicité
logicielle &raquo, ne peut tenir face à une analyse rigoureuse.

Dans le cas pré-cité de la machine à laver, l’effet technique est
l’optimisation du lavage du linge par la machine. Cet effet est obtenu
par l’application d’un procédé de lavage innovant, consistant en
l’adjonction de lessive à tel ou tel moment du cycle de lavage, par la
réalisation d’un meilleur brassage de l’eau et du linge, etc., toutes
opérations effectuées par la machine dans le monde matériel. Le
logiciel de contrôle de la machine, lui, ne fait que mettre en oeuvre
ce procédé innovant de lavage, mais n’en est pas la source. C’est le
procédé qui est innovant et produit l’effet technique souhaité, et
non le logiciel.

Un logiciel, exécuté par un ordinateur, ne fait que manipuler des
quantités symboliques selon un programme pré-établi, indépendamment de
la manière dont ces quantités symboliques sont matérialisées à
l’intérieur de l’ordinateur qui exécute le programme (électrons,
photons, moments magnétiques, états quantiques, etc). L’ordinateur,
pour interagir avec le monde physique, a besoin de périphériques,
destinés à matérialiser les quantités symboliques manipulées par le
programme en actions physiques sur le monde extérieur :
activation d’un servo-commande, émission d’une information lumineuse
déterminée sur un afficheur, etc. Le logiciel de pilotage de la
machine à laver peut ainsi être exécuté sur un simulateur, et
s’exécuter de façon identique à celle dont il le ferait au sein de la
machine à laver, sans pour autant provoquer l’effet technique
attendu. C’est donc que l’effet technique est indépendant du logiciel
considéré, mais réside dans la mise en oeuvre effective du procédé.

Le législateur avait déjà analysé cette situation pour en tirer les
conséquences qui s’imposent, et autoriser la revendication de procédés
industriels. Le fabricant de machines à laver innovantes peut donc
revendiquer son procédé de lavage innovant et la machine qui le réalise
sans avoir besoin le moins du monde de brevets logiciels.

Remarquons pour conclure qu’un logiciel additionnant deux quantités de
réactifs dans les cuves d’un réacteur chimique pourrait être considéré
comme technique selon la doctrine de la technicité logicielle, mais ne
le serait pas s’il s’agissait d’additionner les soldes de deux comptes
bancaires d’un client, alors qu’il s’agit bien de la mise en oeuvre
du même processus.

On ne peut pas, de même, considérer qu’un logiciel produit un effet
technique lorsqu’il « permet d’effectuer des opérations
plus rapidement » ou « améliore l’efficacité
d’un ordinateur ». Remarquons tout d’abord que cette
doctrine est encore plus radicale que celle de la technicité
logicielle, en ce qu’elle permettrait de considérer comme
« technique » tout logiciel offrant de
meilleures performances de traitement que les logiciels existants,
sans référence à un problème donné, ou plutôt en considérant que toute
utilisation d’un ordinateur constitue en soi une application
technique.

L’efficacité réelle d’un algorithme donné étant entièrement dépendante
de l’architecture de l’ordinateur sur lequel il a été implémenté et
s’exécute, les caractéristiques prétendument techniques d’un
algorithme ne lui sont donc pas liées, mais sont basées sur
l’adéquation entre le matériel sous-jacent et des considérations
d’implémentation qui appartiennent au domaine du droit d’auteur, car
spécifiques à chaque réalisation particulière de logiciel pour une
architecture donnée. La considération d’efficacité accrue
n’est donc pas opérante pour définir une frontière stable entre logiciels
prétendument « techniques » et
« non-techniques ».

L’impossible formalisme de la doctrine de la technicité logicielle

L’impossibilité conceptuelle à discriminer entre logiciels
« techniques » et « non
techniques » voue d’avance à l’échec toute tentative de
mettre cette discrimination en oeuvre au sein de textes
législatifs. Un exemple flagrant de cet échec est le texte proposé par
la présidence Irlandaise qui, tout en se défendant d’autoriser une
brevetabilité logicielle totale, arrive effectivement à ce résultat.

Le Considérant 7b, censé restreindre la brevetabilité logicielle, est
contredit par le Considérant 13 et l’Article 2b qui disent explicitement
qu’un logiciel peut à lui seul effectuer une « contribution
technique », et par l’Article 5b qui autorise le brevetage
de logiciels effectuant de tels « contributions
techniques ». Ces articles permettent à n’importe quel déposant
de breveter tout type de logiciel, car ceux-ci sont toujours créés pour
résoudre un problème donné. Ainsi, M. David Sant, représentant officiel
de l’Office Européen des Brevets auprès des institutions européennes,
a confirmé dans une conférence au Parlement Européen l’interprétation
officielle de l’OEB, qui attribue une contribution
technique à toute situation dans laquelle on peut dire qu’il faut
considérer des facteurs techniques avant de commencer à programmer,
situation dans laquelle se retrouvent tous les concepteurs de
logiciel, et qui rend inopérant l’Article 4a censé limiter la
brevetabilité logicielle aux seuls logiciels prétendument
« techniques ».

Le choix du législateur ne peut donc, en l’espèce, être en
demie-teinte : ou bien il assume pleinement la mise en place
d’un régime de brevetabilité logicielle totale, ou bien il la rejette
entièrement, à l’image de la doctrine élaborée par le Parlement
Européen lors du vote de la directive en première lecture, qui rejette
les revendications logicielles, tout en autorisant le brevetage
d’inventions matérielles et de procédés recourant à des logiciels pour
leur mise en oeuvre, ce qui était déjà le cas par le passé, puisque
c’est là même le sens de l’Article 52.2 de la Convention Européenne du
Brevet.

Ce choix binaire, aux conséquences économiques et stratégiques
considérables, ne peut donc se faire à la légère, d’autant plus que
l’extension de la brevetabilité au logiciel serait en pratique
irréversible.

Les brevets logiciels sont-ils juridiquement nécessaires ?

Certains acteurs du dossier excipent de l’Article 27 des accords
ADPIC, qui requièrent l’existence de brevets pour tout domaine
de la technique, pour justifier la nécessité juridique des brevets
logiciels.

Comme l’a souligné M. Paul Hartnack, Comptroller General de l’Office
des Brevets du Royaume-Uni, cette interprétation n’est pas la seule
possible. On peut considérer, comme la Commission et le Conseil
l’ont fait dans leurs propositions de directive, que le logiciel est
intrinsèquement technique, et que donc l’Article 27 d’ADPIC oblige à
disposer de brevets logiciels. On peut tout aussi considérer, comme
l’a fait le Parlement Européen, que le logiciel n’appartient pas
au domaine de la technique mais à celui des oeuvres de l’esprit,
et donc au delà de la portée de l’Article 27 d’ADPIC.

Ici encore, toute latitude est laissée au politique pour trancher,
car le choix entre les deux doctrines reste possible.

Brevetabilité logicielle et droit d’auteur sont exclusifs

Jusqu’à présent, les régimes du droit d’auteur et du brevet
avaient coexisté sans conflit, leurs objets étant différents,
puisque le droit d’auteur s’attachait à la protection des
auteurs d’oeuvres individuelles, tandis que le brevet
s’attachait à la protection des inventeurs de procédés
innovants mis en oeuvre au sein d’appareils (non uniques)
permettant de résoudre un problème donné.

L’extention du système des brevets aux logiciels constitue le premier
empiètement majeur sur le régime du droit d’auteur, dans lequel le
législateur avait, après mûre réflexion, fait entrer le
logiciel. Cette assimilation était somme toute naturelle car le
logiciel, tout comme le livre, consiste en la production d’une oeuvre
textuelle originale (le code source du programme), résultant de la
mise en forme d’idées élémentaires simples. Pour un roman d’aventures,
ces idées élémentaires peuvent être : « scène d’amour
sur un balcon », « jumeaux se faisant passer
l’un pour l’autre », etc. Pour le logiciel, ce peuvent
être : « tri alphabétique dans une liste »,
« affichage d’une barre de progression pour faire patienter
l’utilisateur », etc.

À la différence du droit d’auteur, qui protège l’oeuvre finale, le
brevet logiciel, qui protège contre l’imitation des caractéristiques,
permet de protéger ces idées individuelles, et donc d’empêcher
quiconque de réaliser un programme mettant en oeuvre une idée
protégée. Ceci reviendrait dans le cas du livre à pouvoir revendiquer
des idées élémentaires comme la scène d’amour sur un balcon, alors que
pourtant la même idée donne lieu a des réalisations très différentes,
comme les scènes de Roméo et Juliette et celle de Cyrano de Bergerac,
qui ne sont pas des plagiats l’une de l’autre.

Le brevet logiciel, en premettant à son détenteur de revendiquer les
idées élémentaires, constitue donc un outil anti-concurrentiel
extrêmement puissant, car le détenteur d’un unique brevet peut exiger
l’arrêt de la commercialisation de tous les logiciels implémentant
cette idée, quels qu’en soit les domaines d’application.

En ce sens, la brevetabilité logicielle peut être considérée comme
contrevenant aux accords ADPIC et OMPI. En effet, l’Article 10 d’ADPIC
stipule explicitement que les logiciels doivent être régis par le
régime du droit d’auteur, et l’Article 13 d’ADPIC, tout comme
l’Article 10 de l’accord OMPI, que l’on ne peut systématiquement
porter préjudice aux intérêts légitimes des ayant-droits. Or, le fait
de considérer les logiciels comme brevetables porte effectivement
atteinte au droit des auteurs, puisque l’auteur d’un logiciel original
peut être empêché de le diffuser au prétexte que ce logiciel violerait
un ou plusieurs brevets logiciels, sans que des considérations
d’exceptions comme l’atteinte à la morale publique puissent être
invoquées. De plus en
plus de créations artistiques faisant intervenir des logiciels (les
jeux vidéo, par exemple), les occasions de conflit ne peuvent donc
que se multiplier, au détriment de la création dans les industries
concernées.

Même si l’on peut arguer que ces articles d’ADPIC ne s’appliquent
qu’aux seules exceptions que le législateur pourrait introduire au
sein même du droit d’auteur, il n’en reste pas moins que, vis-à-vis de
l’esprit de ces traités, la création de toutes pièces de la
brevetabilité logicielle, en dehors de toute nécessité juridique, a
plutôt un effet déstructurant que structurant sur les différents
régimes de propriété intellectuelle existant à ce jour, et nul
ne sait quelles pourraient être les conséquences à long terme
de l’extension du régime de la brevetabilité à des domaines pour
lesquels il n’avait certainement pas été conçu, ni pour lequel
il n’a de justification économique.

La décision d’introduire les brevets logiciels revient à
répondre implicitement à la question de savoir qui du système des
brevets ou du droit d’auteur doit avoir la prééminence, sans
aucune possibilité de débat ni pouvoir vérifier la validité de
cette approche.

Le système du droit d’auteur était orienté vers la protection des
oeuvres existantes, déjà accessibles au public puisque déjà créées,
l’existence de la protection permettant justement de régler de façon
contractuelle les modalités d’accès du public à ces oeuvres.

Le système du brevet logiciel permet, lui, de revendiquer une idée,
indépendamment du fait qu’il existe déjà ou non des réalisations
concrètes mettant en oeuvre ces idées et pouvant bénéficier au
public.

Dans le cas du logiciel, privilégier le brevet par rapport au droit
d’auteur équivaut donc à privilégier les comportements défensifs et
anti-concurrentiels inhérents aux brevets, basés sur l’exclusion et
l’obtention de rentes, par rapport au comportement actif du créateur
d’oeuvres originales mettant celles-ci à la disposition du public dans
un cadre de libre concurrence.

Analyse économique de la brevetabilité logicielle

L’analyse juridique de la brevetabilité logicielle présentée ci-dessus
a permis de montrer qu’il n’existe aucune obligation juridique, par
les traités internationaux ADPIC par exemple, de les créer. Bien
au contraire même, l’existence des brevets logiciels est créatrice
d’incohérence et d’insécurité juridique pour les ayant droits de
logiciels. La décision de disposer ou non d’une brevetabilité logicielle
totale au niveau de l’Union Européenne peut donc être librement décidée
sur la base des seuls critères économiques et stratégiques.

Une autre conséquence de cette analyse est que, contrairement à ce
qu’annoncent les rédacteurs de la directive, les conditions
de brevetabilité logicielle en Europe seront bien similaires à
celles en vigueur aux États-Unis, ce qui fait que la situation
actuelle des États-Unis en la matière consitue l’exact reflet
de ce qu’elle sera en Europe si la version de la présidence
Irlandaise de la directive était acceptée.

Remarquons également que, au vu de cette analyse dont les bases
conceptuelles sont simples et accessibles à toute personne un tant
soit peu familière avec le domaine, on peut légitimement s’interroger
sur l’apparente ingénuité des rédacteurs de la directive à vouloir
faire croire à l’existence d’une séparation entre logiciels techniques
et non techniques. Si on leur accorde un minimum de crédit, on
arrivera à la conclusion qu’ils ne peuvent qu’être au courant de cette
impossibilité, et il faut alors s’interroger sur leur motivation à
vouloir légitimer la brevetabilité logicielle totale fut-ce au prix
d’une entorse à la vérité.

Si le simple parti pris idéologique ne peut être écarté, il n’est pas
suffisant pour rendre compte de l’ensemble des comportements observés.
On ne peut donc que constater l’existence d’une collusion d’intérêts
économiques entre les dirigeants des offices de brevets, les membres
des différentes commissions d’experts sollicitées pour la rédaction
de la directive, et les responsables des services juridiques de
quelques grandes entreprises, dans le but avéré de donner à ces
dernières les armes juridiques anti-concurrentielles les plus
efficaces possibles, sachant que les services juridiques de ces
entreprises sont les plus gros clients des offices de brevets,
qui eux-mêmes vivent des redevances sur les brevets acceptés, et
qu’il existe une grande porosité professionnelle entre ces trois
milieux.

Revendications logicielles, interopérabilité, et monopoles

L’analyse de la version de la directive soutenue par la
présidence Irlandaise montre que ce texte fait une part très
importante à la possibilité de créer et maintenir des monopoles
sur des pans entiers de l’industrie informatique, sans aucune
contrepartie pour le consommateur.

L’Article 5b de ce texte introduit les revendications de
programmes, qui permettent de poursuivre tout créateur, vendeur, ou
utilisateur de logiciel, pour peu qu’un brevet ait été accordé sur
l’une des idées élémentaires que ce logiciel implémente. Ceci
permettrait aux grandes entreprises disposant de services juridiques
étoffés d’effrayer les utilisateurs potentiels de logiciels
concurrents, avant même le recours aux tribunaux, distordant ainsi la
concurrence de façon insidieuse.

Ce texte nie également tout droit à l’interopérabilité. L’Article 6 ne
fait que maintenir les exceptions de rétro-ingénierie et de
décompilation prévues par la directive de 1991 sur la protection du
logiciel par le droit d’auteur. Mais alors que ces exceptions sont
suffisantes dans le contexte du droit d’auteur, elles sont sans effet
dans le contexte des brevets, puisque tout fabricant de logiciel
réimplémentant, dans un but d’interopérabilité, des méthodes de
traitement d’un format de fichier breveté serait en contrefaçon du
brevet.

Le mode de création du logiciel, basé sur l’innovation cumulative,
et le cycle de développement très court de cet industrie, ne permettent
pas de plus de justifier l’existence d’un système des brevets jugé
coûteux, lourd et lent.

En effet, à la différence d’avec le monde matériel, le temps
nécessaire à un concurrent pour imiter un logiciel est à peine plus
faible que le temps pris pour développer le logiciel original, car le
développement proprement dit constitue l’activité la plus coûteuse en
comparaison du simple fait d’avoir l’idée du logiciel, ce qui fait que
dans ce marché très réactif les innovateurs initiaux ont le temps de
tirer le bénéfice de leurs produits avant qu’un compétiteur ne se
présente.

De plus, un tel compétiteur ne peut gagner des parts de marché que si
son produit est de meilleure qualité, apporte des innovations
supplémentaires, ou bien est moins cher que le produit original, ce
qui ne peut se faire, comme les coûts de développement sont identiques
d’après ce qui précède, que si le prix de vente du produit original
était trop élevé. La preuve en est que, sur un segment de marché
donné, un produit de bonne qualité et à un prix raisonnable a peu de
compétiteurs.

Ainsi, sans brevets logiciels pour construire des monopoles, la
compétition, l’innovation, et les consommateurs sont favorisés. Ces
consommateurs sont à la fois les particuliers et les entreprises de
toutes tailles et de tous secteurs d’activité, car l’impact des
technologies de l’information sur la productivité affecte tous les
secteurs de l’économie.

Pour conclure, notons que le brevet n’apporte de même aucune
information qui ne soit déjà publique, puisque les fonctionnalités du
logiciel protégées par le brevet apparaissent naturellement à l’usage
de ce logiciel, permettant à tout « homme de
l’art » d’en saisir le fonctionnement. Remarquons de plus
que le jargon utilisé pour rédiger ces brevets est en général
incompréhensible pour tout informaticien, et d’un niveau technique si
bas qu’il n’apporte aucune information utilisable en pratique, puisque
le but de la rédaction du brevet est d’être la plus généraliste
possible afin de bloquer le plus de compétiteurs possible.

La menace économique des brevets logiciels pour l’industrie informatique européenne

Selon un rapport du Commissariat général au Plan français datant de
2002, l’économie du logiciel en France repose pour l’essentiel sur de
petites structures. Ainsi, 58 % des 28 500 entreprises du secteur
comptent deux employés au maximum. Ces chiffres sont à peu près
équivalents en Allemagne et dans les autres pays de l’Union. Les
Petites et Moyennes Entreprises du secteur du logiciel représentent
plus de 70 % des emplois et de la richesse produite par ce
secteur en Europe, sans compter les services informatiques des grandes
entreprises industrielles et de services (banques, assurances, etc)
contribuant pour une très grande part au développement de logiciel
"maison", qui ne sera jamais distribué commercialement, mais pourraient
néanmoins faire l’objet d’attaques en contrefaçon de brevet logiciel.

Les petites entreprises sont en moyenne plus innovantes, plus
réactives, et plus enclines à baser leur développement sur la création
de nouveaux produits plutôt que sur un système établi de rentes
monopolistiques. De fait, puisque les PME du logiciel représentent
la majorité économique du secteur, et un vivier de créativité
nécessaire au développement de technologies nouvelles, c’est à leur
profit que doivent être conçues les règlementations.

Concernant l’introduction de la brevetabilité logicielle en Europe, ce
même rapport du Commissariat Général au Plan voit dans la
« décision abrupte d’extension de la brevetabilité aux
logiciels[...] des dangers réels pour l’industrie européenne,
du fait du déséquilibre considérable qui existe entre les États-Unis
et l’Europe en la matière », et précise que
« Seule la paix armée qui prévaut actuellement, du fait de
l’incertitude juridique qui entoure la notion de brevet de logiciel,
explique en effet que les brevets existants [les 30 000 brevets
logiciels douteux déjà délivrés par l’OEB] ne soient pas plus fréquemment
utilisés ».

Un système d’incitation à l’innovation ne peut être efficace que
s’il encourage effectivement la production de produits finis
bénéficiant aux citoyens et donc à la société dans son ensemble.
En revanche, la monopolisation des concepts amont défavorise la
production de tels biens, car il est alors plus rentable pour un
acteur économique ayant breveté un concept d’obtenir des royalties
vis-à-vis des entités prenant le risque commercial de réaliser les
produits finis, plutôt que de concevoir lui-même de tels produits et
de risquer de se trouver en butte aux attaques de la part de ses
semblables. Ainsi, plus la portée du brevet est large et étendue dans
le temps, et plus on encourage les comportements de prédation,
l’absence de prise de risque, au détriment de l’innovation. Dans le
cas du logiciel, la durée minimale de 20 ans, qui serait imposée par
les accords ADPIC si l’on considérait le logiciel comme brevetable,
représente plus de 10 fois la durée de vie commerciale moyenne d’un
logiciel, ce qui n’a économiquement aucun sens, car cela bloque les
développements ultérieurs d’autres innovateurs, qui doivent, pour
pénétrer le marché, acquitter des royalties sur des idées de base dont
le coût de développement, si tant est qu’il y en ait eu un, a déjà été
maintes fois remboursé.

Au mieux les grands acteurs passent-ils entre eux des accords
d’échanges de portefeuilles de brevets, ce qui leur permet de se
croire dans un monde sans brevets, mais ceci a plusieurs effets
pervers. D’abord, quel intérêt économique y a-t-il pour ces
entreprises, donc pour leur clients et par extenion pour la société
dans son ensemble, à financer le dépôt de brevets servant à contrer
l’existence d’autres brevets, alors que l’absence de brevets
reviendrait exactement au même ? Ensuite, à l’issue de tels
échanges, les seules entités ayant à supporter le coût des licences
sont les petites et moyennes entreprises innovantes, qui ne peuvent
ainsi accéder aux marchés qui rentabiliseraient leurs
investissements. Le système fonctionne donc exactement à l’opposé de
comme il le devrait, pénalisant abusivement les PME.

Les brevets logiciels sont de plus un danger pour les investisseurs.
Sans brevets, tout investisseur est certain de pouvoir commercialiser
les logiciels qu’il a financé, et donc d’avoir un retour sur
investissement si ces produits trouvent un marché. Avec un système de
brevets logiciels, tout logiciel économiquement valable est
attaquable, et le retour sur investissement est plus incertain. La
très récente étude exhaustive menée aux États-Unis sur plus de 130.000
brevets logiciels et 1600 entreprises étasuniennes entre 1976 et nos
jours a montré que les dépenses en brevets logiciels se sont
substituées à plus de 10 % des dépenses de R&D des entreprises,
au niveau national. Lors d’auditions de la Federal Trade Commission
sur le sujet, certains dirigeants d’entreprises étasuniens ont même
indiqué qu’ils allaient consacrer jusqu’à 35 % de leurs dépenses
de Recherche et Développement à se constituer des portefeuilles de
brevets logiciels afin de tenter de se prémunir contre des attaques en
contrefaçon, sans que ces coûteux portefeuilles les protègent
aucunement des frais de contentieux élevés qu’un concurrent pourrait
vouloir les voir débourser, au détriment de leur compétitivité à
moyen et long terme.

Dans ce contexte, il est légitime de penser que, parce que le marché
permettant le meilleur retour sur investissement sera une Europe sans
brevets logiciels, les entreprises les plus à même d’y réussir seront
les entreprises européennes, plus proches de leur clients, et plus à
même de fournir les efforts de R&D nécessaires. Toute entreprise
basant son développement logiciel aux États-Unis peut faire l’objet
d’une attaque en contrefaçon sur la base des brevets logiciels
étasuniens, puisque les développeurs codent, sciemment ou non, des
algorithmes brevetés sur le sol étasunien. En revanche, les
développeurs européens seront libres de réaliser leurs logiciels sans
contraintes. Ainsi, une Europe sans brevets logiciels peut même
réussir à attirer des entreprises étasuniennes soucieuses d’y
pérenniser leurs développements, renversant le sens des flux
migratoires des informaticiens.

Remarquons d’ailleurs que rien n’empêche une entreprise européenne de
déposer des brevets aux États-Unis pour essayer d’augmenter ses
chances de pénétrer ce marché. Cet investissement est minime en
comparaison de celui à réaliser pour obtenir des brevets européens, et
sans commune mesure avec le tribut que les PME européennes devraient
verser aux grandes entreprises étasuniennes si les brevets logiciels
étaient légalisés en Europe.

Dernière mise à jour : 16 mai 2004
Auteur : François PELLEGRINI