Autres chroniques d'Isabelle
Renard
|
|
Le logiciel est un élément d'actif
dont on reconnaît de plus en plus l'importance, même s'il fait encore
l'objet d'un traitement comptable peu représentatif de sa valeur réelle
pour l'entreprise.
Pourtant, le logiciel est peu ou mal protégé,
ce qui se comprend car il faut bien dire que le logiciel est un drôle d'oiseau
: pour commencer, il est immatériel. Pris séparément, il
est totalement inutile, il suffit de regarder une disquette dans les yeux pour
s'en apercevoir. Le logiciel est totalement dépendant de son environnement
: à titre d'illustration, le code source d'un logiciel développé
pour un environnement Unix pour un type de matériel donné ne sera
que de peu d'utilité si on entend l'utiliser sur un mainframe muni d'un
système d'exploitation propriétaire.
Il existe néanmoins
des moyens très efficaces pour protéger son patrimoine logiciel,
mais encore faut-il prendre conscience d'un certain nombre de principes, que nous
allons développer, si l'on nous permet ce raccourci, en deux temps et trois
mouvements :
La protection du logiciel :
- deux situations
- trois usages
- deux méthodes
Deux
situations
Le logiciel peut s'apprécier selon deux perspectives différentes,
selon qu'on est dans la position de celui qui l'utilise ou dans la position de
celui qui le développe.
Ce qui importe à l'utilisateur est d'être
certain qu'il pourra toujours utiliser un logiciel dont il détient la licence,
même si l'éditeur disparaît ou change de métier. De
plus en plus, les entreprises sont dépendantes de logiciels de gestion
structurants, dont l'implémentation est coûteuse tant en terme de
prix d'acquisition que d'organisation et d'appropriation par le personnel. Changer
au bout de deux ans son logiciel de gestion de ressources humaines alors qu'on
avait planifié de le garder au moins dix ans est une opération à
laquelle aucun manager n'a envie d'être confronté.
Dès lors, l'entreprise utilisant un logiciel considéré comme
structurant et stratégique devra s'assurer qu'en cas de défaillance
de l'éditeur, elle dispose des éléments nécessaires
pour assurer, ou plutôt faire assurer, les opérations de support
et de maintenance. On l'aura compris, disposer en ce cas d'une simple disquette
contenant le logiciel source ne sera que de peu de secours, si l'on n'a pas accès
à la documentation de conception et que l'on ne sait pas sur quel environnement
matériel et système le compiler pour obtenir un exécutable.
Ce qui importe au créateur de logiciel est
de disposer de preuves d'antériorité suffisamment crédibles
pour pouvoir prouver sa "paternité" sur le logiciel en cas de
situation de contrefaçon, que ce soit en défense ou en demande.
En défense, il devra prouver qu'il est le véritable créateur
du logiciel si un tiers exploite ou commercialise une version contrefaisante ;
en sens inverse, il doit pouvoir prouver qu'il est l'unique développeur
du logiciel si une action en contrefaçon est intentée contre lui.
Pour se faire, il aura dû constituer des preuves de sa "paternité",
qui sont d'ordre purement privées puisque, contrairement à la marque
ou au brevet, le logiciel ne fait pas l'objet d'un dépôt officiel.
Une telle preuve pourra être constituée par le dépôt
du seul code source chez un tiers ; elle pourra aussi, et constituera alors une
présomption plus convaincante de la paternité du déposant,
être constituée par un dépôt complet (source + documentation
de conception + environnement de développement), tenu régulièrement
à jour.
Trois usages
La protection du logiciel au moyen d'un
dépôt répond à trois usages, les deux premiers d'inférant
directement des éléments que nous venons d'aborder.
- Le premier usage est celui qui consiste à
pallier la défaillance d'un éditeur, en disposant de suffisamment
d'éléments pertinents sur l'environnement de production et d'exploitation
du logiciel pour en faire reprendre la maintenance et le support par un tiers
spécialisé :
- Le second usage correspond à la constitution
de preuves sur la paternité d'un logiciel, et cet usage correspond typiquement
au besoin des éditeurs (qui vivent de leurs droits sur le logiciel). Mais
il répond aussi au besoin de toutes les sociétés qui développent
des logiciels spécifiques adaptés à leur métier et
qui constituent un véritable avantage concurrentiel sur lequel elles veulent
assurer leurs droits.
Ce qui nous mène directement au troisième
des usages que l'on peut attendre d'un dépôt, qui est lié
à la protection de savoir-faire non breveté, et qui intéresse
plus particulièrement les entreprises qui travaillent dans le domaine de
l'innovation. Il existe en effet des situations dans lesquelles un savoir faire
brevetable n'est volontairement pas déposé, pour des raisons liées
au secret, ou encore au coût lié au dépôt multinational
d'un brevet que l'on est pas sûr d'exploiter. Pour autant, il est essentiel
de conserver des traces de l'existence de ce savoir faire, afin d'opposer son
antériorité à un tiers concurrent pour bloquer son dépôt
de brevet ou obtenir des redevances sur l'invention considérée.
Dans un tel cas, le dépôt de l'ensemble de la documentation de conception,
assortie le cas échéant d'un logiciel si l'invention s'y prête,
peut se révéler une aide estimable pour prouver sa paternité
sur l'invention considérée.
Deux méthodes
On l'aura compris, il existe deux types
de dépôt de logiciel :
- L'un est le dépôt du code source
de type "enveloppe Soleau", qui peut en pratique se traduire par le
dépôt du code chez un agent assermenté, et dont l'objet est
de garantir une date certaine au code déposé.
- A l'autre extrémité, un dépôt
"complet" comprendra l'ensemble de la documentation de conception et
de développement, et aura fait l'objet d'une validation technique complète
sur l'environnement de développement. Un tel dépôt crée
une présomption forte de paternité du déposant, dans la mesure
où l'on peut difficilement imaginer qu'un autre que le créateur
du logiciel puisse se livrer à cette opération. Par ailleurs, seul
un dépôt de ce type permet d'assurer à l'utilisateur du logiciel
la garantie qu'il sera en mesure de faire assurer le support de celui ci en cas
de défaillance de l'éditeur.
En conclusion
Une politique bien comprise de la protection
du patrimoine logiciel de l'entreprise nécessite de proportionner les moyens
mis en uvre à la nature de l'actif logiciel considéré
:
- Les progiciels structurants utilisés par
l'entreprise devront faire l'objet d'un dépôt complet, afin de pouvoir
en assurer le support en cas de défaillance de l'éditeur.
- Les logiciels créés par l'entreprise pourront, selon le cas et
selon leur valeur pour l'entreprise, faire l'objet d'un dépôt complet
(présomption forte de paternité du déposant) ou d'un dépôt
" enveloppe soleau ", qui aura à tout le moins le mérite
de créer une antériorité.
- Enfin, le savoir faire non breveté pourra faire l'objet d'un dépôt
complet à titre de preuve d'antériorité sur l'invention considérée.
|