Protéger un logiciel : mécanismes de protection juridique

Un logiciel peut cumuler plusieurs mécanismes de protection. Aucun ne couvre, à lui seul, le code, les personnes qui y ont contribué et les informations qui doivent rester confidentielles.

• Droit d’auteur : il protège les formes originales du programme.
• Preuves : elles permettent de dater les versions et d’identifier les contributions.
• Contrats : ils organisent la titularité des droits et les usages autorisés.
• Secret : il concerne certaines informations qui ne sont pas divulguées.
• Brevet : il peut viser une invention technique mise en œuvre par ordinateur, mais pas un programme pris isolément.

Protéger les formes originales par le droit d’auteur

Le droit d’auteur naît sans dépôt lorsque le logiciel est original. Il peut couvrir notamment le code source et le code objet ainsi que le matériel de conception préparatoire susceptible de conduire au programme. En revanche, les idées et principes à la base des éléments du logiciel, la seule fonctionnalité, le langage de programmation ou un format de fichiers ne sont pas protégés comme forme d’expression du programme.

L’étendue de la protection dépend des choix créatifs démontrés. Une architecture imposée par des contraintes techniques, des standards ou des composants tiers ne doit pas être présentée comme entièrement appropriable. L’article L. 112-2 du Code de la propriété intellectuelle inclut expressément les logiciels et leur matériel de conception préparatoire parmi les œuvres protégées, ce qui confirme la place du droit d’auteur comme socle de protection.

Établir la preuve des versions et des contributions

Une preuve de date ne crée pas le droit et ne démontre pas, à elle seule, la titularité. Elle devient utile lorsqu’elle est reliée à une version identifiable, aux auteurs et aux contrats correspondants. Le guide sur le dépôt et l’horodatage d’un logiciel compare la portée des principaux moyens de preuve.

• Conservez le code, les dépôts Git, tickets, livraisons et journaux de développement.
• Figez les versions importantes avec leur empreinte, leur documentation et la liste des composants tiers.
• Utilisez, selon le besoin, un dépôt spécialisé, une e-Soleau, un acte de commissaire de justice ou de notaire, ou un horodatage électronique adapté.
• Gardez les certificats, récépissés et échéances de conservation avec le paquet réellement déposé.

Cartographie interne des preuves

À titre de méthode d’organisation, il est utile de tenir, en interne, un inventaire à jour associant chaque version marquante du logiciel à :

• la liste des personnes ayant contribué et leur statut au moment de la contribution ;
• les contrats ou dispositions qui régissent leurs droits ;
• les composants tiers intégrés et la nature de leurs conditions d’utilisation ;
• les documents préparatoires susceptibles d’être invoqués au titre de la protection.

Cet inventaire n’a pas d’effet juridique propre. C’est une trame de gestion qui rend plus rapide la production des pièces attendues en cas de litige ou de due diligence.

Sécuriser la chaîne des droits

Pour les logiciels et leur documentation créés par des employés dans l’exercice de leurs fonctions ou d’après les instructions de leur employeur, l’article L. 113-9 prévoit en principe la dévolution des droits patrimoniaux à l’employeur, sauf dispositions ou stipulations contraires. Cette règle vise la situation de l’employé placé dans le cadre défini par le texte ; elle ne règle pas d’elle-même la titularité pour toute autre situation, ce qui explique la place centrale des contrats pour organiser les cessions ou les concessions de droits.

Les contrats doivent identifier les livrables, les droits cédés ou concédés, les territoires, la durée, les usages, la rémunération et les garanties adaptées. Cartographiez aussi les bibliothèques open source, composants commerciaux, API, données, modèles et contenus dont les licences continuent à s’appliquer. Une exploitation accordée à un tiers doit notamment être cadrée dans une licence de logiciel.

Points de vigilance sur les licences ouvertes

De manière plus générale, un logiciel distribué peut combiner des composants soumis à des licences différentes. Sans se substituer à l’analyse de chaque licence applicable, il est prudent, à titre de méthodologie interne, de tenir un inventaire à jour des composants intégrés et de leurs conditions d’utilisation. Cet inventaire aide à préparer les questions à poser aux juristes lorsque des choix de distribution ou de modèle économique sont envisagés, en particulier lors des versions majeures ou d’une opération sur la société.

Protéger le savoir-faire et les secrets

Le code non diffusé, les paramètres, données d’entraînement, méthodes, feuilles de route et informations d’exploitation peuvent, selon leurs caractéristiques, relever de la catégorie du secret des affaires. Cette qualification obéit à ses propres conditions légales, distinctes de celles du droit d’auteur, et suppose notamment que les informations ne soient pas généralement connues et qu’elles fassent l’objet de mesures raisonnables destinées à en préserver le caractère secret. Limitez les accès, segmentez les environnements, tracez les transmissions et prévoyez la restitution ou la suppression à la fin des missions. Pour les ensembles de données exploités par le logiciel, vérifiez séparément les conditions de protection des bases de données.

Une mention « confidentiel » ou un accord générique ne suffit pas si les accès restent ouverts. À l’inverse, publier le code ou décrire une méthode dans un brevet peut faire perdre le caractère secret des informations divulguées. Le choix entre secret et publication est donc structurant et doit être décidé avant toute communication externe, dépôt ou publication scientifique.

Quand envisager un brevet ?

Un programme d’ordinateur pris en tant que tel est exclu de la brevetabilité. Une invention mise en œuvre par ordinateur peut toutefois être brevetable lorsqu’elle présente un caractère technique et satisfait aux critères de nouveauté, d’activité inventive et d’application industrielle. Devant l’OEB, le programme doit produire un effet technique supplémentaire allant au-delà des interactions physiques normales entre logiciel et matériel.

L’intérêt d’un brevet dépend du marché, de la durée de vie du produit, de la facilité de détection d’une contrefaçon, du budget et des possibilités de contournement. Toute divulgation avant le dépôt doit être évaluée, car elle peut affecter la nouveauté.

Grille de décision : droit d’auteur, secret ou brevet ?

Sans préjuger d’un cas concret, quelques questions simples aident à orienter l’arbitrage :

• l’élément est-il d’abord une forme d’expression (code, documentation), ou une solution technique caractérisable ?
• garder l’information hors du domaine public reste-t-il possible dans le modèle d’exploitation prévu ?
• la détection d’une reprise par un tiers serait-elle réaliste dans les conditions d’usage habituelles ?
• le calendrier du produit permet-il d’absorber la durée d’un dépôt et d’un examen ?

Ces questions ne remplacent pas l’analyse de brevetabilité ou l’examen des conditions du secret, mais elles évitent d’engager des efforts sur une voie manifestement inadaptée.

Construire une protection cohérente

Commencez par inventorier les versions, les auteurs, les contrats, les composants tiers et les informations secrètes.

Choisissez ensuite les preuves et les protections en fonction des risques : copie du code, départ d’un prestataire, divulgation d’un procédé, dépendance open source ou exploitation internationale. Si une reprise non autorisée est suspectée, l’analyse de la contrefaçon de logiciel commence par les éléments protégés, la chaîne des droits et les versions comparables. Revoyez cette cartographie lors des versions majeures, des acquisitions et des changements de modèle économique.

Pour bâtir cette stratégie, consultez notre accompagnement en protection des logiciels.