Mathieu MARTIN, Avocat Associé

Le sommet « Choose France » qui s’est déroulé  ce lundi 19 mai 2025 à Versailles vise à attirer des investisseurs en France.

Les investissements peuvent se concrétiser de différentes manières dont des prises de participation au sein d’entités préexistantes via le plus souvent des opérations de levée de fonds.

Or, tout investisseur/acquéreur  souhaite, par définition, sécuriser son investissement et donc limiter  les risques de son opération.

Ceci amène dès lors à mener un audit (due diligence) portant sur des périmètres variés :

• Audit financier
• Audit technique
• Audit juridique : conformité à la législation sociale, fiscale, au droit des sociétés mais aussi la sécurisation (ou non) d’un patrimoine immatériel  d’une activité dans le monde du numérique

Il n’est pas rare  de découvrir, lors d’une due diligence, que l’audit juridique révèle que la cible envisagée par un investisseur détient bon moins d’actifs que son activité aurait pu laisser à penser, voire que la société cible elle-même découvre qu’elle détient bien moins de droits qu’elle ne le croyait.

Ainsi, on peut découvrir, dans l’ignorance d’ailleurs de tous les acteurs partie prenante de l’opération, cédant comme acquéreur/investisseur, que la société cible exploite sans droit  ni titre des créations ou développement logiciels.

Nous envisagerons donc ci-après quelles vérifications minimum doivent être menées en matière de due diligence portant sur la vérification des droits associés à des créations  logicielles.     

Les associés ne sont pas des salariés

Il est usuel de rencontrer des situations où l’un des associés a développé, et continue à développer,  un logiciel qui est exploité par sa société.  De l’avis de tous, la société est donc titulaire des droits sur le logiciel. Juridiquement, une telle affirmation est moins évidente

En effet, l’article l 113-9 du code de la propriété intellectuelle (CPI)  dispose : 

Sauf dispositions statutaires ou stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l’exercice de leurs fonctions ou d’après les instructions de leur employeur sont dévolus à l’employeur qui est seul habilité à les exercer.

Ce texte ne vise donc que les salariés pour opérer une dévolution des droits sur le logiciel à l’employeur (et encore « sauf dispositions statutaires ou stipulations contraires » ).

Un associé n’est pas un salarié.

Ainsi, un associé qui n’a pas également le statut de salarié n’a pas automatiquement cédé ses droits sur ses développements logiciels.

Il faudra alors vérifier si l’associé a cédé ses droits à la société :

• Via une convention distincte
• Dans le cadre d’une disposition des statuts de la société 
• Selon une stipulation d’un pacte d’associé

Et ce, de manière précise, complète et détaillée, en accord avec les disposions de l’article L131-3 du CPI qui dispose :

la transmission des droits de l’auteur est subordonnée à la condition que chacun des droits cédés fasse l’objet d’une mention distincte dans l’acte de cession et que le domaine d’exploitation des droits cédés soit délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée.

Notons, que nous pouvons opérer le même raisonnement pour un représentant légal  qui n’est pas, de fait, un salarié .

L’audit pourra aussi amener à découvrir que la société cible né détient qu’une simple licence d’exploitation de la part de l’associé ou du représentant légal, auteur du développement.

« Payer n’est pas céder »     

« J’ai fait le cahier des charges et j’ai payé le développement :  il m’appartient ». Rien n’est mon vrai en matière de créations logicielles.

En effet, il convient de rappeler 2 principes

Tout d’abord, le droit d’auteur régissant également le droit des logiciels, , l’article L 111-1 du CPI dispose :

L’auteur d’une œuvre de l’esprit jouit sur cette œuvre, du seul fait de sa création, d’un droit de propriété incorporelle exclusif et opposable à tous.

(…) L’existence ou la conclusion d’un contrat de louage d’ouvrage ou de service par l’auteur d’une œuvre de l’esprit n’emporte pas dérogation à la jouissance du droit reconnu par le premier alinéa, sous réserve des exceptions prévues par le présent code

Ainsi, et même si une commande a été réalisée, l’auteur reste titulaire de sa création, sauf exception visée plus haut au titre d’une dévolution des droits par le salarié sur leurs créations logicielles

Ensuite, la conclusion d’un contrat, et le paiement associé, n’entrainent pas de fait une cession des droits d’auteurs : encore faut-il que le contrat conclu stipule également une cession des droits portant sur les créations, comme rappelé plus en avant en application de l’article L 131-3 du CPI.

Ceci amène, dans le cadre d’une due diligence, à identifier si des tiers ont concouru au développement d’une solution logicielle, et, dans l’affirmative, analyser le périmètre des droits cédés.  A titre d’exemple, on vérifiera l’existence d’un droit de faire évoluer le développement logiciel, de le maintenir. 

« C’est de l’Open source, je peux faire ce que je veux »   

Pour rappel l’open source peut se définir comme un code source librement accessible ( par opposition à un code dit « propriétaire » et donc non accessible). Or cet accès n’est pas sans règle. C’est en effet dans le cadre de son monopole de droit, que l’auteur va choisir que l’accès à sa création ne sera pas restreint, mais au contraire  très permissif, et  selon les termes d’une licence qu’il aura choisie.

• Soit sur la base de modèles existants ; exemple licence GPL, MIT, BSD
• Soit  rédigées par ses soins

Ne pas respecter  les termes de cette licence équivaut donc à violer les droits d’auteur et commettre un acte de contrefaçon. 

Il n’est pas rare de découvrir, lors d’un audit, que la société cible a utilisé différentes briques logicielles « open source » pour développer son application, sans respecter les termes de leurs licences associées et surtout, en s’estimant seule titulaire des droits sur son développement.

Or, et le plus souvent, les licences open source ont pour paradigme

• un principe de redistribution de toute évolution apportée à une code source mis à disposition,  pour justement éviter le phénomène dit de « logiciel propriétaire »
• un principe d’interdiction de redistribution à titre onéreux du code
• pour certaines licences, un phénomène dit de « contamination » où tout code « propriétaire »  associé à un code source dit « open » doit également devenir open source .

Un telle analyse, lors d’un audit, peut amener à découvrir que la valorisation estime des actifs logiciels, fondée sur la croyance d’un code exclusif, propriétaire, et concédés à des clients finaux comme tels, n’est qu’une fiction.

CONCLUSION

Selon la nature de l’investissement envisagé, un audit des droits portant sur les créations  logicielles  peut s’avérer nécessaire. Cet audit impliquera également

• une revue des contrats relatifs à la commercialisation desdites solutions logicielles. L’objectif sera de s’assurer que les droits détenus par les clients ne sont pas de nature à remettre en cause  le patrimoine informationnel de la société.
• Une revue de contrats conclus avec des prestaires tiers le cas échéant au fonctionnent de la solution logicielle ( hébergeur , fournisseur de bases de données, API…. –   
• Une revue des différents signes distinctifs associés à l’exploitation du logiciel (marques , nom de domaine….et la vérification de leurs titulaires )

Enfin, un tel audit juridique pourra utilement être accompagné par un audit technique. Lors d’un tel audit, il sera notamment vérifié que le code source est documenté. En effet, et lorsqu’une solution logicielle constitue le cœur d’activité d’une société, encore faut-il s’assurer de sa capacité à pouvoir la maintenir la faire évoluer sur la durée et ce, indépendamment des connaissances des personnes travaillant à date sur la solution logicielle.