Vous venez de développer un logiciel et souhaitez une protection maximale de celui-ci. Si vous êtes le développeur de ce logiciel, vous en êtes l’auteur et le propriétaire. Mais vous l’avez peut-être fait développer par un tiers développeur et dans ce cas, il faut au préalable vous être assuré d’en avoir la propriété pleine et entière.
Dans le meilleur des cas, vous avez pu obtenir une protection de votre logiciel par le biais d’un dépôt de brevet (voir notre fiche pratique intitulée « Comment protéger son invention par un brevet».
Pour autant, vous vous inquiétez de ce qui peut se passer lors de la commercialisation de votre produit : est-ce que vos clients, vos partenaires, ne vont pas tenter de décomposer, analyser votre produit pour pouvoir l’exploiter eux-mêmes tout en se passant de vos services ? Il s’agit de pratiques « d’ingénierie inversées » et ces pratiques sont encadrées par la loi. Voici un bref résumé de vos droits et nos conseils associés.
I. Qu’est-ce que « l’ingénierie inversée »?
Les pratiques « d’ingénierie inversée » sont aussi appelées « rétroingénierie », « rétroconception » et en anglais « reverse engineering ».
Ces pratiques permettent dans certaines conditions à l’utilisateur de votre logiciel d’analyser, légalement et sans votre autorisation, le programme de votre logiciel de sorte qu’il puisse comprendre son fonctionnement et l’utiliser correctement. L’utilisateur pourra ainsi reproduire le code du logiciel ou traduire la forme de ce code, dès lors qu’il répond aux conditions posées par la loi (article L.122-6-1 IV du Code de la propriété intellectuelle). Le risque est que cet utilisateur puisse créer une copie, voire développer une version améliorée de votre logiciel sans que vous puissiez vous réclamer d’une quelconque atteinte à vos droits.
Il y a donc des pratiques d’ingénierie inversée qui sont autorisées (pour comprendre et correctement utiliser un logiciel) et des pratiques qui sont interdites (pour copier voire améliorer votre logiciel, souvent à des fins commerciales).
Vous comprenez donc d’emblée l’enjeu de bien appréhender la réglementation applicable : votre objectif est d’encadrer cette pratique de façon à éviter que les utilisateurs de votre logiciel ne se saisissent de cette autorisation légale de pratiquer l’ingénierie inversée à des fins préjudiciables à votre entreprise.
II. Les pratiques d’ingénierie inversée sont-elles légales ?
Les pratiques d’ingénierie inversées ne sont pas prohibées par la loi française, mais sont strictement encadrées par l’article L.122-6-1 IV du Code de la propriété intellectuelle.
En effet, l’article L.122-6-1 IV du Code de la propriété intellectuelle autorise les pratiques de « reproduction du code du logiciel ou la traduction de la forme de ce code » sans le consentement de l’auteur lorsque cette reproduction ou cette traduction est « indispensable pour obtenir les informations nécessaires à l’interopérabilité du logiciel »
La rétroingéniere est donc légale sous trois conditions principales :
- l’utilisateur doit avoir un droit d’utiliser le logiciel ou y être habilité (par le biais d’une licence ou autre contrat;
- l’analyse a été rendue nécessaire car l’utilisateur ne disposait pas des informations suffisantes pour permettre l’interopérabilité c’est-à-dire « la capacité de logiciels ou de protocoles différents à fonctionner ensemble ;
- les actes d’ingénierie inversée sont limités aux parties du logiciel nécessaires à cette interopérabilité.
Toutefois, ces pratiques restent limitées. En effet, l’utilisateur ne pourra ni transmettre les informations obtenues à des tiers —sauf si celles-ci sont nécessaires à l’utilisation du logiciel—, ni commercialiser un logiciel similaire.
Si un utilisateur de votre logiciel reconstitue son fonctionnement par décompilation ou désassemblage, sans votre autorisation et à des fins commerciales, vous pourrez le poursuivre pour contrefaçon.
Attention à la clause d’ingénierie inversée dans vos contrats de licence
Attention à ne pas prévoir de clause interdisant de manière absolue les pratiques d’ingénierie inversée car celle-ci serait frappée de nullité.
En revanche, vous pouvez prévoir que : les tiers signataires du contrat ne seront pas autorisés à effectuer de l’ingénierie inversée, à décompiler, à désassembler le logiciel, ni à aider d’autres à le faire ou faciliter de telles opérations, sauf accord écrit entre les parties et dans la limite expressément permise par la loi applicable à des fins d’interopérabilité.
III. Conseils pratiques pour éviter les risques d’ingénierie inversée
Voici quelques conseils pratiques afin de vous aider à éviter des pratiques autorisées d’ingénierie inversée :
- communiquer les informations utiles afin que l’utilisateur ne puisse pas invoquer l’impossibilité de l’interopérabilité, c’est-à-dire l’incompatibilité pour interagir avec d’autres logiciels.
- évitez de communiquer le code-source du logiciel ;
- mettre en place des mesures de protection technique qui n’empêchent pas l’interopérabilité.
Si vous êtes victime de pratiques d’ingénierie inversée en dehors du contexte autorisé par la loi, vous pourrez poursuivre les utilisateurs (ou tiers) en contrefaçon de vos droits de propriété intellectuelle.
Note : l’obligation d’information incombant au propriétaire du logiciel
Si, en qualité de propriétaire du logiciel, vous refusez de transmettre à l’utilisateur les informations nécessaires à la bonne utilisation du logiciel, celui-ci pourra demander à l’Hadopi (la Haute autorité pour la diffusion des œuvres et la protection des droits sur internet) de se prononcer sur la question.
Cette autorité, créée par la loi n°2009-669 du 12 juin 2009, a notamment pour mission la régulation et la veille dans le domaine des mesures techniques de protection. Dans le cadre de cette mission, elle peut être saisie par tout éditeur de logiciel, fabricant de système technique et exploitant de service souhaitant obtenir des informations essentielles à l’interopérabilité en vertu de l’article L.331-32 du Code de la propriété intellectuelle.
En tant que propriétaire des droits sur votre logiciel, vous ne pourrez alors imposer à vos utilisateurs de renoncer à la publication du code source et de la documentation technique que si vous apportez la preuve que celle-ci aurait pour effet de porter gravement atteinte à la sécurité et à l’efficacité de la mesure technique.
