À qui appartient le code que vous livrez vraiment ?

C'est l'un des malentendus les plus tenaces du métier. Un client commande un site e-commerce ou une application mobile, règle la facture, récupère les fichiers livrés et considère que le code lui appartient désormais sans réserve. Pourtant, le droit français raisonne à l'inverse.

Le code source est qualifié d'œuvre de l'esprit au sens du Code de la propriété intellectuelle (article L112-2). Le logiciel y est expressément cité parmi les œuvres protégées. Conséquence : c'est l'auteur — vous, le développeur — qui détient les droits patrimoniaux dès l'écriture de la première ligne, et non celui qui finance la commande.

Le paiement de la prestation rémunère le travail de développement, pas le transfert de propriété intellectuelle. Ce sont deux choses distinctes. Sans clause de cession explicite et écrite dans le contrat ou le devis, le client n'obtient, au mieux, qu'un droit d'usage implicite, et encore : l'étendue de ce droit est floue et source de contentieux.

Cette règle n'est pas une subtilité théorique. Elle explique pourquoi tant de relations cordiales tournent au conflit le jour où le projet prend de la valeur : revente, levée de fonds, changement de prestataire. Tant que tout va bien, personne ne se pose la question de savoir qui détient les droits. Le problème surgit toujours au pire moment, quand un tiers — investisseur, acquéreur, nouvel intervenant — exige une chaîne de propriété claire que personne n'a pris le soin d'établir.

À noter : une exception majeure existe pour le salarié. Lorsqu'un logiciel est créé par un employé dans l'exercice de ses fonctions, l'article L113-9 du Code de la propriété intellectuelle prévoit une dévolution automatique des droits à l'employeur. Mais cette dévolution ne joue que pour le salariat : elle ne s'applique ni au freelance, ni au prestataire indépendant, ni à l'agence. Si vous facturez en tant qu'indépendant, vous restez par défaut titulaire de vos droits, peu importe que vous ayez été payé.

Une cession valable ne se résume pas à une phrase du type « le code devient la propriété du client ». Le Code de la propriété intellectuelle (article L131-3) impose un formalisme précis : chaque droit cédé doit être délimité dans son étendue, sa destination, son lieu et sa durée.

Concrètement, votre contrat devrait préciser :

• Les droits cédés : droit de reproduction, de représentation, de modification, d'adaptation.
• L'étendue territoriale : France, Europe, monde entier.
• La durée : durée légale de protection ou période limitée.
• Les supports et destinations : web, mobile, revente à des tiers, intégration dans un autre produit.

À défaut, vous conservez vos droits — mais le client, lui, croit le contraire. Le jour où il veut revendre sa plateforme, la confier à un autre prestataire ou lever des fonds avec un audit technique, le malentendu explose. Et c'est généralement à ce moment-là que la lettre d'avocat arrive.

Un contrat clair sur la cession des droits n'est pas une formalité : c'est votre première ligne de défense contre un litige en propriété intellectuelle.

Aucun développeur ne code tout depuis zéro. Vous assemblez des dizaines de paquets npm, des composants React, des librairies sous licence MIT, Apache, GPL ou AGPL. Chacune impose ses propres conditions — et certaines sont contaminantes.

Les licences dites « copyleft » comme la GPL ou surtout l'AGPL peuvent obliger à publier sous la même licence l'ensemble du code qui les intègre. Si vous livrez à un client une application propriétaire qui embarque, sans le savoir, un composant AGPL, vous l'exposez à devoir ouvrir tout son code — l'inverse exact de ce qu'il attendait.

Le danger se niche souvent dans les dépendances transitives : vous installez un paquet apparemment anodin, qui en tire dix autres, dont l'un est placé sous une licence restrictive. Quelques exemples de pièges classiques :

• Une librairie de génération de PDF ou de graphiques sous GPL, intégrée au cœur d'une application commerciale.
• Une fonte ou un jeu d'icônes dont la licence interdit l'usage commercial sans mention.
• Un composant en AGPL utilisé côté serveur, qui déclenche l'obligation de mise à disposition du code même sans distribution du logiciel.
• Du code copié depuis un dépôt public sans aucune licence : par défaut, il n'est tout simplement pas réutilisable.

Ce risque est rarement compris, et pourtant il engage directement votre responsabilité de professionnel : vous aviez un devoir de conseil sur les briques que vous avez choisies. Un client lésé peut réclamer la réécriture complète du module incriminé, plus le préjudice commercial associé.

La bonne pratique consiste à tenir un inventaire des dépendances (un fichier de licences, ou SBOM), à exécuter un scan de licences avant chaque livraison majeure, et à documenter par écrit, dans le contrat, les composants tiers utilisés et leur régime. C'est précisément ce type de faute — une atteinte involontaire à la propriété intellectuelle d'un tiers, ou un conseil défaillant sur les licences — que couvre une assurance RC Pro adaptée au développement.

Voici comment, en pratique, un flou sur la propriété du code se transforme en réclamation financière :

1. Le client veut revendre sa plateforme. L'acquéreur exige un audit juridique. L'absence de cession des droits bloque la transaction. Le client vous tient pour responsable du préjudice.
2. Le client change de prestataire. Vous refusez (légitimement) de transférer le code, faute de cession. Le client invoque un abus et réclame des dommages-intérêts pour rupture de continuité de service.
3. Un tiers conteste un composant. Un éditeur dont la librairie a été mal licenciée engage une action. Le client se retourne contre vous au titre du devoir de conseil.

Dans chacun de ces cas, ce n'est pas un « bug » qui est en cause, mais une faute professionnelle de nature juridique. Les frais de défense, à eux seuls, peuvent dépasser plusieurs milliers d'euros avant même qu'une responsabilité ne soit tranchée.

Un point que beaucoup de clients — et de développeurs — ignorent : même une cession totale et parfaitement rédigée ne transfère que les droits patrimoniaux, c'est-à-dire le droit d'exploiter le code. Le droit moral de l'auteur, lui, est en principe incessible et perpétuel.

Pour le logiciel, la loi a toutefois prévu un régime atténué : l'auteur ne peut, sauf stipulation contraire, s'opposer aux modifications apportées par le cessionnaire ni exercer son droit de repentir. En clair, votre client peut faire évoluer le code librement une fois les droits patrimoniaux cédés. Mais le droit à la paternité — être reconnu comme auteur — subsiste.

Pourquoi cela compte ? Parce que la frontière entre ce qui se cède et ce qui ne se cède pas alimente des malentendus. Un client peut croire qu'il a acheté un droit absolu et illimité, alors que certaines prérogatives restent attachées à votre personne. Mieux vaut clarifier ces points dans le contrat plutôt que les découvrir lors d'un désaccord — par exemple si vous souhaitez mentionner le projet dans votre portfolio et que le client s'y oppose.

La parade tient en deux volets complémentaires :

• Côté contrat : intégrez systématiquement une clause de cession des droits conforme à l'article L131-3, conditionnée au paiement intégral, et un inventaire des licences open source utilisées.
• Côté assurance : une RC Pro qui couvre expressément l'atteinte à la propriété intellectuelle et la faute professionnelle, frais de défense inclus.

Pensez aussi à la clause de réversibilité : elle organise, dès la signature, la remise du code source, de la documentation et des accès en cas de fin de relation. Couplée à la cession conditionnée au paiement intégral, elle évite la situation la plus toxique — un client qui réclame un transfert avant d'avoir réglé, ou un développeur accusé de rétention parce que rien n'avait été prévu.

La clause vous protège en amont ; l'assurance prend le relais quand, malgré tout, le litige survient — car même un développeur irréprochable peut être assigné. La RC Pro pour développeurs prend en charge votre défense et l'indemnisation due, là où une assurance généraliste exclut purement et simplement les dommages immatériels. Si vos projets manipulent des données personnelles, une option Cyber complète la couverture sur le volet sécurité et fuite de données.

Pour comprendre l'ensemble des garanties spécifiques à votre activité, consultez notre page dédiée au développement web et mobile.