Protéger un logiciel en Ouzbékistan : droit d'auteur, brevet ou secret

Une startup fintech de Tachkent — résidente de l'IT Park, chiffre d'affaires en hausse, un investisseur prêt à mener le tour de table. Lors de la due diligence, l'avocat de l'investisseur pose une seule question : « Montrez-moi les documents par lesquels le droit exclusif sur le code appartient à l'entreprise. » Il n'y en a aucun. Le cœur du produit a été écrit pendant trois ans par un développeur principal engagé comme indépendant via un contrat de prestation, sans la moindre clause de cession de droits. Selon la loi, les droits patrimoniaux sur ce code lui appartiennent, à une personne physique — et non à la société que l'investisseur s'apprêtait à financer. Le tour s'est figé pendant deux mois, le temps que les parties rédigent une cession a posteriori — et le développeur, comprenant désormais sa position, a relevé son prix. Cet article explique lequel des trois régimes protège votre logiciel en Ouzbékistan, et les trois failles par lesquelles le droit fuit hors de l'entreprise avant même que vous ayez commencé à le protéger.

Trois régimes : ce que chacun couvre réellement

Un logiciel n'est pas un objet unique, mais un empilement de couches. Code source et objet, architecture, algorithmes, interface, données, et le nom même du produit. Chaque couche se protège avec un outil différent, et les confondre est l'erreur la plus fréquente des fondateurs.

• Le droit d'auteur protège l'expression — le code source et objet concret, traité comme une œuvre littéraire. Il naît automatiquement au moment de la création et couvre la forme, pas l'idée.
• Le brevet protège une solution technique — mais pas le programme « en tant que tel ». En Ouzbékistan, un programme d'ordinateur est expressément exclu des objets brevetables ; ce que l'on peut breveter, c'est une invention mise en œuvre dans un logiciel, lorsqu'elle produit un effet technique.
• Le secret des affaires protège ce que vous ne devez surtout pas montrer : un algorithme, une formule, une architecture, un fichier clients. Il protège l'idée et le savoir-faire — précisément ce que le droit d'auteur n'atteint pas — mais seulement tant que le secret reste secret.

Ces régimes ne se concurrencent pas, ils se cumulent. Un produit mature est généralement protégé par les trois à la fois : le code par le droit d'auteur, l'algorithme clé par un régime de secret, le nom et le logo par une marque, et, là où cela compte, l'apparence de l'interface par un dessin industriel.

Droit d'auteur : il naît seul, mais l'enregistrement reste utile

La nouvelle essentielle pour un fondateur : pour que votre code soit protégé par le droit d'auteur, vous n'avez rien à enregistrer. Le droit naît du seul fait de la création de l'œuvre — c'est le principe fondateur de la loi « Sur le droit d'auteur et les droits voisins », et les programmes d'ordinateur y figurent expressément comme des œuvres protégées au même titre que les œuvres littéraires.

Alors pourquoi payer un enregistrement ? Parce qu'un droit d'auteur est facile à détenir et difficile à prouver. Quand un concurrent sort un produit suspectement similaire et que vous allez au tribunal, la première question est : « Prouvez que vous avez écrit ce code, et que vous l'avez écrit en premier. » Le Centre PI tient un registre d'État des programmes d'ordinateur et des bases de données ; l'enregistrement est facultatif et donne un certificat avec une date fixe et un fragment de code déposé. Il ne « crée » pas le droit — vous l'avez déjà — mais il transforme un litige « ma parole contre la vôtre » en un litige contre un document officiel, avec une date de priorité de votre côté.

Faut-il enregistrer chaque version ? Non. On enregistre les versions qui comptent : la première version commerciale, les sauts de version majeurs, le build qui précède un tour de table ou une opération. La taxe d'État pour l'enregistrement d'un programme se compte en quelques centaines de milliers d'UZS ; consultez le barème en vigueur du Centre PI, révisé environ une fois par an. Au regard du coût de développement, c'est une somme symbolique pour un document qui vaut, au tribunal, plus que n'importe quel témoignage.

Ce que l'enregistrement ne fait pas : il ne vérifie pas l'originalité du code et ne garantit pas que vous n'avez violé aucun droit d'autrui. Le certificat acte que « ce code existait chez cette personne à cette date » — rien de plus. Si vous avez intégré une bibliothèque tierce sous une licence incompatible, le certificat ne vous sauvera pas.

Brevet : quand un algorithme est tout de même brevetable

La tentation de « breveter l'algorithme » saisit un fondateur technique sur deux. En Ouzbékistan, cela ne marche pas frontalement : un programme d'ordinateur en tant que tel n'est pas une invention au sens de la loi sur les brevets, pas plus que les algorithmes ou les méthodes mathématiques. Un brevet protège la solution technique d'un problème, pas une suite d'instructions.

La frontière passe par l'effet technique. Si votre logiciel est une logique métier, une interface ou une façon d'organiser des données, il n'y aura pas de brevet. Mais si le programme commande le fonctionnement d'un appareil, traite un signal d'une manière nouvelle, accroît les performances ou économise une ressource de façon techniquement mesurable — vous avez potentiellement une invention « mise en œuvre dans un logiciel ». La revendication se rédige alors non sur le code, mais sur le procédé ou le dispositif.

Quand cela vaut la peine : un brevet a du sens lorsque la solution est difficile à cacher (elle se voit au fonctionnement du produit, la rétro-ingénierie est réaliste) et, en même temps, difficile à contourner. En revanche, si votre avantage vit dans un code que personne ne voit, un brevet ne fait que nuire : la demande divulgue le fond de la solution, n'offre en Ouzbékistan que 20 ans de protection, et seulement dans les pays où vous avez obtenu le brevet. Plus de détails sur le choix entre un dépôt national et un dépôt étranger auprès de notre équipe brevets.

Secret des affaires : le régime qui protège l'idée

Ce que le droit d'auteur n'atteint pas (l'idée, l'algorithme, la méthode) et ce que vous ne voulez pas divulguer dans un brevet, c'est le régime du secret des affaires qui le protège. L'Ouzbékistan dispose d'une loi dédiée « Sur le secret commercial », qui fonctionne sur le principe « protégé exactement autant que vous le protégez vous-même ».

Le mot clé est régime. Une information ne devient pas un secret d'elle-même, mais seulement une fois que vous avez instauré et documenté des mesures de protection :

• approbation d'une liste des informations constituant le secret (code source du cœur, architecture, paramètres des modèles, fichier clients) ;
• restriction de l'accès et tenue d'un registre de qui est habilité à quoi ;
• insertion d'une obligation de confidentialité dans les contrats de travail et les contrats de prestation, appuyée par un NDA ;
• marquage des supports de la mention « Secret des affaires ».

Si aucun régime n'est en place, juridiquement il n'y a pas de secret : un développeur qui part en emportant l'algorithme chez un concurrent n'a rien violé, car il n'y avait rien à protéger. Pour une société de logiciels, un régime de secret n'est donc pas une formalité, mais l'unique protection de la couche la plus précieuse du produit — celle que, par principe, on ne montre jamais, ni dans un registre ni dans un brevet.

Œuvre de salarié et contrats de prestation : où le droit fuit

Revenons à la startup du début. Son erreur est la plus coûteuse et la plus fréquente de la tech. Voici à qui appartient le code dans trois situations types.

Salarié. Le code écrit par un salarié dans le cadre de ses fonctions est une œuvre de salarié. En droit ouzbek, le droit exclusif appartient par défaut à l'employeur, tandis que l'auteur conserve le droit au nom et un droit à rémunération. Cela joue en votre faveur — mais seulement si le développeur a un contrat de travail et si ses fonctions et sa mission sont formulées de sorte que le code litigieux en relève. « Le développeur a bâti sur son temps libre un service hors de ses tâches » n'est plus une œuvre de salarié, et le droit reste chez lui.

Prestataire, freelance, équipe externalisée. Ici, le réglage par défaut est inverse : le droit exclusif reste chez l'auteur-exécutant tant que le contrat ne prévoit pas expressément qu'il est transféré (cédé) au donneur d'ordre. Un contrat de prestation ou d'entreprise ne transfère pas de lui-même le droit sur le code — il porte sur le travail, pas sur la propriété intellectuelle. C'est précisément ce qui a brûlé la startup du début : prestations payées, procès-verbaux signés, et le droit sur le code resté chez une personne physique.

Cofondateur sans rien sur papier. La configuration la plus explosive : deux personnes bâtissent le produit « sur la confiance », sans contrats de travail ni accord de répartition des droits. Chacun est coauteur, le droit est commun, et il ne s'exerce qu'ensemble. Quand l'un part, il emporte la moitié des droits sur le produit — et peut bloquer une opération ou une licence.

Pour un fondateur, il n'y a qu'une leçon : le droit exclusif n'apparaît pas tout seul dans l'entreprise. Vous l'obtenez soit comme employeur via l'œuvre de salarié (avec une relation de travail dûment documentée), soit en le prenant à l'exécutant par une cession écrite. La mécanique de la cession d'un droit exclusif figure dans notre analyse du contrat de cession ; pour le code, les principes qui régissent une marque s'appliquent : sans document écrit, le droit n'est pas transféré.

Open source : la licence qui peut devenir un piège

Presque tout produit moderne est bâti sur des bibliothèques tierces, et chacune vient avec sa propre licence. Les licences permissives (MIT, BSD, Apache 2.0) autorisent l'usage dans un produit propriétaire presque sans condition — il suffit de conserver la mention d'attribution. Les licences copyleft (GPL, AGPL) fonctionnent autrement : elles exigent qu'une œuvre dérivée soit distribuée aux mêmes conditions, c'est-à-dire avec le code source ouvert.

Le piège : en intégrant un composant GPL dans le cœur de votre produit fermé, vous pouvez vous retrouver tenu d'ouvrir aussi votre propre code — et pour le SaaS, l'AGPL est particulièrement dangereuse, car elle considère même la fourniture d'un accès via un réseau comme une « distribution ». Pour une entreprise qui vend du logiciel fermé, c'est la perte de l'avantage même pour lequel le code a été écrit.

Le minimum pratique : tenez un registre de toutes les dépendances tierces avec leur licence (les fichiers manifestes de vos dépendances sont le brouillon de ce registre), séparez les composants copyleft du cœur propriétaire et vérifiez les licences avant qu'une bibliothèque n'entre dans une version — pas pendant la due diligence qui précède le tour.

Comment choisir un régime : un court arbre de décision

• Est-ce du code, une interface, de la documentation ? → droit d'auteur automatiquement ; enregistrez les versions clés au Centre PI.
• Est-ce une solution technique à effet mesurable, visible au fonctionnement du produit ? → envisagez un brevet.
• Est-ce un algorithme ou un savoir-faire que vous ne montrez jamais ? → instaurez un régime de secret des affaires.
• Est-ce l'apparence de l'interface, des icônes, des animations ? → ajoutez un dessin industriel.
• Dans tous les cas : réglez la question de la titularité — contrats de travail avec mission écrite, cessions des prestataires, audit open source.

En bref

• En Ouzbékistan, c'est le droit d'auteur qui protège le code, pas un brevet ; le brevet ne vaut que pour une solution technique mise en œuvre dans un logiciel.
• Le droit d'auteur naît seul, mais enregistrer le programme au Centre PI vous donne une date de priorité et un document pour le tribunal — enregistrez les versions clés.
• Le secret des affaires protège l'idée et l'algorithme, mais uniquement avec un régime de confidentialité en place (liste, contrôle d'accès, NDA, marquage).
• Le droit n'apparaît pas automatiquement dans l'entreprise : avec un salarié, une œuvre de salarié en votre faveur ; avec un prestataire, non, tant qu'une cession n'est pas signée.
• L'open source sous licence copyleft (GPL, AGPL) peut vous forcer à divulguer votre code fermé — tenez un registre des dépendances.

Questions fréquentes

Dois-je enregistrer un programme d'ordinateur pour qu'il soit protégé ? Non. Le droit d'auteur naît automatiquement au moment de la création. L'enregistrement au Centre PI est facultatif et sert non pas à créer le droit mais à le prouver : le certificat fixe la date et le contenu du code, ce qui tranche le litige sur qui a écrit le produit et quand.

Puis-je breveter une application mobile ? L'application en tant que programme — non, elle est protégée par le droit d'auteur. Ce qui est brevetable, c'est une solution technique en son sein : une nouvelle manière de traiter des données, de commander un appareil, de compresser ou de transmettre un signal avec un effet technique mesurable. La logique métier et l'interface échappent au brevet.

À qui appartient le code écrit par un freelance sous contrat ? Par défaut, au freelance. Un contrat de prestation ou d'entreprise paie le travail, mais ne transfère pas le droit exclusif sur le code. Pour que le droit passe au donneur d'ordre, le contrat doit comporter une clause expresse de cession (transfert) du droit exclusif.

Qu'est-ce qu'une œuvre de salarié et pourquoi est-ce important ? C'est une œuvre créée par un salarié dans le cadre de ses fonctions. Le droit exclusif appartient par défaut à l'employeur en droit ouzbek. Pour une entreprise IT, c'est le principal canal légal par lequel le code des salariés devient un actif de la société — mais il ne fonctionne qu'avec un contrat de travail en règle décrivant correctement les fonctions.

Un NDA protège-t-il à lui seul ? Un NDA est nécessaire mais non suffisant. Un secret des affaires est protégé une fois tout le régime en place : une liste approuvée d'informations secrètes, un accès restreint, des supports marqués. Un NDA sans le reste du régime peut ne pas être reconnu par un tribunal comme une mesure de protection suffisante.

Puis-je utiliser une bibliothèque GPL dans un produit commercial ? Oui, mais sous conditions. La GPL exige qu'une œuvre dérivée soit distribuée aux mêmes conditions ouvertes, et l'AGPL étend cette exigence à l'accès SaaS via un réseau. Pour un produit fermé, c'est un risque de divulgation — les composants copyleft doivent être isolés du cœur propriétaire ou remplacés par des équivalents permissifs.

Combien de temps dure le droit d'auteur sur un programme ? Les droits patrimoniaux (exclusifs) durent des décennies — toute la vie de l'auteur et une période substantielle après, au terme de laquelle l'œuvre tombe dans le domaine public. En pratique, cela signifie que les droits sur le code n'« expirent » dans aucun horizon qui vous concerne ; l'important n'est pas la durée, mais qui détient les droits.

Un logiciel paraît immatériel, mais juridiquement c'est un faisceau de droits très concrets — et ils appartiennent, ou non, à votre entreprise. Enregistrer les versions, instaurer un régime de secret et déposer un brevet renforcent la protection, mais tout cela est vain si le droit exclusif sous-jacent a fui vers un prestataire ou un coauteur. Rassemblez d'abord le droit au sein de l'entreprise. Défendre le code d'autrui est un exercice coûteux et perdu d'avance.