Votre code vous appartient peut-être moins que vous ne le croyez. En France, la propriété intellectuelle sur un logiciel s’applique automatiquement – mais elle ne revient pas forcément à celui qui a écrit chaque ligne. Selon votre statut, votre contrat et les outils que vous utilisez, le code que vous produisez ce soir peut légalement appartenir à votre client, à votre employeur, ou à personne.
Ce guide s’adresse aux développeurs qui facturent des missions, aux équipes tech qui recrutent des freelances et aux dirigeants de PME qui commandent du code sans savoir ce qu’ils reçoivent vraiment. Trois scénarios, des règles claires, cinq actions à appliquer cette semaine.
La propriété intellectuelle sur le code : automatique, mais pas là où vous pensez
Contrairement aux brevets, le droit d’auteur ne requiert aucun dépôt, aucune formalité, aucun délai. Dès qu’un développeur écrit du code original, ce code est protégé. L’article L111-1 du Code de la propriété intellectuelle est formel : l’auteur jouit de son droit dès la création de l’oeuvre.
Le mot clé : original. Un code est protégeable s’il porte l’empreinte de la personnalité de son auteur. Une fonction CRUD générique copiée depuis Stack Overflow ? Non protégeable. Une architecture modulaire, des choix de nommage personnels, une organisation non triviale ? Protégeable.
La protection automatique ne dit rien sur qui en bénéficie. Et c’est là que les situations se compliquent selon votre profil.
Développeur salarié vs freelance : deux régimes de propriété intellectuelle opposés
C’est la distinction la plus importante – et la plus souvent ignorée dans les contrats.
Développeur salarié. L’article L113-9 du CPI est sans ambiguïté : les droits patrimoniaux sur un logiciel créé par un employé dans l’exercice de ses fonctions sont dévolus de plein droit à l’employeur. Pas besoin de clause contractuelle, pas de signature supplémentaire. Vous codez sur les horaires de l’entreprise, avec ses outils, pour ses projets ? Le code appartient à l’entreprise. Seuls les droits moraux (paternité, intégrité de l’oeuvre) restent attachés au développeur et sont inaliénables.
Développeur freelance. La règle s’inverse. Par défaut, le prestataire reste titulaire de ses droits d’auteur, même après avoir livré le code et encaissé sa facture. Une commande de développement ne transfère pas les droits : elle rémunère une prestation. Si le client veut être propriétaire du code, il doit obtenir une cession de droits explicite dans le contrat, précisant :
- L’étendue des droits cédés : reproduction, représentation, modification, traduction, distribution
- La durée : limitée dans le temps ou pour toute la durée légale de protection
- Le territoire : France, monde entier, un pays précis
- La contrepartie financière : une cession sans rémunération spécifique peut être fragilisée
Sans cette clause, votre client a le droit d’utiliser le livrable comme prévu – mais pas de le modifier, le revendre, ou le réutiliser dans un autre projet. Une distinction que la majorité des devis de prestation oublient. En Guyane comme en métropole, les développeurs signent souvent des devis simplifiés sans clause PI. Le client repart avec le code, revient deux ans plus tard pour une évolution, et découvre un conflit de droits que personne n’avait anticipé. Notre guide sur le droit numérique pour les PME en 2026 couvre les autres zones de friction réglementaire à anticiper.
Open source : ce que « licence gratuite » ne signifie pas
Intégrer une librairie open source dans votre projet, c’est accepter un contrat. Pas un contrat que vous avez signé – un contrat que vous avez accepté par l’acte d’utilisation. Ignorer ses termes peut coûter cher.
Les licences open source forment un spectre du plus permissif au plus contraignant :
- MIT, BSD, Apache 2.0 : permissives. Utilisation, modification, distribution, y compris dans des projets commerciaux fermés. Obligation : conserver les mentions de copyright et la notice de licence.
- GPL v2/v3 (copyleft fort) : toute application qui intègre du code sous GPL doit elle-même être publiée sous GPL. Si votre SaaS propriétaire embarque une librairie GPL, votre code peut être contaminé. C’est l’effet dit « viral ».
- LGPL (copyleft faible) : l’obligation GPL ne s’applique qu’à la librairie elle-même si vous la liez dynamiquement. Une zone grise que les juristes débattent.
- Pas de licence = copyright exclusif. Un repo GitHub sans fichier LICENSE n’est pas libre de droits : personne n’a le droit de l’utiliser sauf l’auteur.
Le réflexe professionnel : avant d’intégrer une dépendance, vérifiez sa licence. Des outils comme npx license-checker --summary (npm) ou pip-licenses --format=markdown (Python) scannent votre projet en quelques secondes. Dix minutes d’audit qui évitent un litige bien plus long.
Code généré par IA : le vide de propriété intellectuelle qui vous expose
Des études récentes estiment qu’entre 40 % et 60 % du code produit aujourd’hui implique un assistant IA (Copilot, Claude, ChatGPT, Gemini). La question juridique reste largement ouverte – et les risques sont concrets.
En France, seul un être humain peut être titulaire de droits d’auteur. Un code entièrement généré par IA, sans contribution créative humaine prouvée, n’est protégeable par personne. Ni par vous, ni par l’éditeur de l’outil IA. Il tombe dans le domaine public de fait.
Trois risques opérationnels :
- Vous livrez du code que vous ne pouvez pas protéger. Si votre valeur différenciatrice est le code lui-même (algorithme propriétaire, logique métier unique), vous ne pouvez pas en revendiquer la propriété intellectuelle si vous l’avez fait générer sans contribution substantielle.
- Le code généré peut reproduire du code protégé. Les modèles sont entraînés sur des milliards de lignes, dont du code sous GPL ou MIT. En novembre 2025, OpenAI a été condamné par le tribunal de Munich pour reproduction de contenus protégés. La jurisprudence sur le code suit le même chemin.
- L’AI Act modifie les règles pour les éditeurs. Depuis août 2025, l’article 53 de l’AI Act oblige les fournisseurs de systèmes IA généraux à publier un résumé des données d’entraînement protégées. Ce qui ouvre des droits d’opposition aux auteurs et une vague de recours en cours.
La position défendable : documenter votre contribution créative sur le code IA-assisté. Historique de prompts, modifications substantielles, décisions d’architecture prises par vous. C’est ce delta humain qui rend le code protégeable. Sur la dépendance aux plateformes étrangères et les risques de souveraineté liés, notre article sur l’hébergement en France, RGPD et Cloud Act complète ce panorama.
5 actions concrètes pour protéger votre propriété intellectuelle dès aujourd’hui
1. Déposez une preuve d’antériorité pour vos développements clés. L’enveloppe e-Soleau de l’INPI (environ 15 euros pour 5 ans, 300 Mo) horodate vos fichiers sources. C’est opposable aux tiers en cas de litige. L’APP (Agence de Protection des Programmes) propose un dépôt certifié avec documentation technique. À faire sur chaque projet dont la valeur représente plusieurs mois de développement.
2. Ajoutez une clause PI dans chaque contrat de prestation. Que vous soyez côté client ou prestataire, la clause doit figurer explicitement. Si vous êtes développeur freelance et que vous souhaitez conserver vos droits (pour revendre la même librairie à plusieurs clients), dites-le dans le contrat. Si vous commandez du code, obtenez la cession complète par écrit. L’e-signature juridiquement valide permet de sécuriser ces échanges à distance sans délai.
3. Auditez les licences de vos dépendances. Lancez npx license-checker --summary sur votre projet Node ou pip-licenses --format=markdown en Python. Identifiez les licences copyleft (GPL, AGPL) dans votre stack. Chaque GPL dans un logiciel commercial distribué est un risque à traiter.
4. Documentez votre contribution créative sur le code IA-assisté. Conservez les logs de prompts, notez les décisions d’architecture que vous prenez, gardez les versions intermédiaires. Un fichier DESIGN-DECISIONS.md dans le repo suffit à commencer. C’est ce document qui prouve la contribution humaine si les droits sont contestés.
5. Séparez le code interne du code client dans vos repos. Une librairie réutilisée dans plusieurs projets clients doit avoir son propre repo avec sa propre licence. Ne la livrez pas en monolithique dans chaque projet : vous perdez le contrôle de sa diffusion et créez des conflits de droits entre clients.
Le mot de la fin
La propriété intellectuelle sur le code n’est pas une question académique. C’est ce qui détermine si vous pouvez facturer une évolution, si votre client peut revendre votre travail, et si votre stack open source vous expose légalement. Cinq minutes de vérification contractuelle en amont évitent des mois de contentieux en aval.
♚ 1D-D1 – One Day or Day One. Parlons stratégie →
