Qui possède le code de votre développeur freelance ?

Vous avez payé la facture. Le code tourne en production. Vous pensez qu'il est à vous.

En droit belge, ce n'est pas automatique. Et depuis qu'une partie des lignes sort d'un assistant, la question a changé de nature : il ne s'agit plus seulement de savoir qui détient les droits, mais de savoir s'il y a des droits à détenir.

Ce que la facture ne transfère pas

Un logiciel est protégé par le droit d'auteur. Le Code de droit économique assimile les programmes d'ordinateur, matériel de conception préparatoire compris, aux œuvres littéraires (art. XI.294 CDE). La protection suppose que le programme soit original, et elle porte sur l'expression, pas sur les idées et principes qui la sous-tendent (art. XI.295 CDE).

L'auteur, c'est celui qui l'a écrit. Une personne physique. Le paiement d'une prestation de développement rémunère un travail : il n'opère pas, à lui seul, un transfert des droits patrimoniaux sur le résultat.

Trois situations, trois régimes.

Le code écrit par un salarié

La loi du 19 avril 2014, qui a inséré le livre XI « Propriété intellectuelle » dans le Code de droit économique, prévoit une présomption : l'employeur est présumé cessionnaire des droits patrimoniaux sur les programmes créés par ses employés. La présomption vaut pour le code écrit dans l'exercice de leurs fonctions ou d'après ses instructions (art. XI.296 CDE). Une disposition contractuelle ou statutaire contraire l'écarte.

Deux mots comptent dans cette phrase. Présumé : c'est une règle supplétive, une convention ou un statut peut l'écarter. Employés : la présomption est d'interprétation stricte et ne s'étend pas à qui n'est pas dans un lien de subordination.

Le code écrit par un indépendant

Aucune présomption équivalente. Freelance, agence, consultant, stagiaire sous convention d'immersion : la cession doit être organisée par le contrat. À défaut, le prestataire reste titulaire des droits patrimoniaux sur ce qu'il a écrit. Le paiement n'y change rien. Votre cahier des charges non plus.

Le cahier des charges ne fait pas de vous un auteur. Donner des instructions détaillées, financer, valider les livrables : rien de tout cela n'emporte cession.

Le cas qu'on oublie : le freelance qui facture via sa société

C'est la configuration la plus fréquente en Belgique, et le maillon le plus souvent cassé.

Vous contractez avec la SRL de votre développeur. Mais le code a été écrit par une personne physique : le gérant. Or la présomption de l'article XI.296 vise l'employeur et ses employés. Un gérant indépendant qui travaille pour sa propre société n'est en principe pas son employé. Résultat possible : la SRL vous cède des droits qu'elle n'a jamais elle-même acquis.

La chaîne de titularité a donc deux maillons, pas un :

1. du développeur personne physique à sa société ;
2. de sa société à vous.

Une clause propre couvre les deux. Elle fait intervenir la personne physique à l'acte. Autre voie : la société garantit qu'elle détient bien les droits qu'elle cède, avec une déclaration nominative des personnes ayant contribué au code.

Les clauses à vérifier

1. Une cession expresse des droits patrimoniaux

La formule « le client est propriétaire des livrables » ne suffit pas. Elle désigne un support, pas un droit. Ce qu'il faut, c'est une clause qui vise expressément la cession des droits patrimoniaux d'auteur sur le logiciel, code source compris.

Le droit belge est peu accommodant sur ce terrain : à l'égard de l'auteur, la cession se prouve par écrit et s'interprète restrictivement (art. XI.167 CDE). Ce qui n'est pas écrit n'est pas cédé. Une clause vague ne se lit pas en votre faveur : elle se lit en faveur de l'auteur.

Vérifiez aussi que la cession couvre le code futur livré après la signature, évolutions, correctifs, modules ajoutés en cours de route, et pas seulement le périmètre initial.

2. L'étendue de la cession

Une cession peut être limitée. Vérifiez qu'elle couvre :

• les modes d'exploitation que vous envisagez, énumérés ;
• la durée et le territoire ;
• le droit d'adapter, de corriger et de faire évoluer le code, y compris par un autre prestataire que celui qui l'a écrit ;
• le droit de sous-licencier et de céder à votre tour, sans accord préalable (une revente d'entreprise ne doit pas dépendre de la signature de votre ancien développeur).

Le droit de modification est le point qui bloque le plus souvent. Une cession qui ne le prévoit pas transforme chaque évolution de votre produit en négociation.

Il existe un filet de sécurité légal, mais il est étroit. L'acquéreur légitime d'un logiciel peut accomplir les actes nécessaires à son utilisation conforme à sa destination, y compris la correction d'erreurs. La Cour de justice a même admis la décompilation pour corriger un bug (CJUE, 6 octobre 2021, Top System, C-13/20). L'arrêt porte sur la directive 91/250/CEE, codifiée depuis par la directive 2009/24/CE. C'est une exception de dépannage, pas un droit de faire évoluer votre produit. Elle ne remplace jamais une clause.

3. La livraison des sources, et ce qui se passe si le prestataire disparaît

Beaucoup de contrats livrent un exécutable et gardent les sources chez le prestataire. Techniquement, vous ne pouvez alors plus faire évoluer votre produit sans lui, quelle que soit la qualité de votre clause de cession.

Exigez donc, en plus de la cession : les sources livrées effectivement, de la documentation technique et des scripts de build, à chaque jalon, sur un dépôt dont vous détenez le compte. Si le prestataire refuse, cas fréquent quand il exploite une base commune à plusieurs clients, passez par un dépôt fiduciaire (escrow) avec des cas de libération définis : faillite, cessation d'activité, défaut de maintenance persistant.

4. Le sort du code tiers

Votre prestataire ne peut pas vous céder ce qu'il ne possède pas. Un projet moderne embarque des dizaines de bibliothèques open source, parfois un composant sous licence commerciale, parfois du code réutilisé d'un projet antérieur.

Demandez un inventaire des dépendances et de leurs licences (un SBOM, en langage technique). Certaines licences libres imposent des obligations qui remontent jusqu'à votre produit, notamment si vous le distribuez. Ajoutez une garantie du prestataire sur l'origine du code, sur l'absence d'atteinte aux droits de tiers, et une clause d'indemnisation qui tienne, plafonnée, mais pas symbolique.

Vérifiez aussi le sens inverse : beaucoup de contrats contiennent une clause discrète. Le prestataire y conserve ses « outils, briques et savoir-faire préexistants » et ne vous en concède qu'une licence. Ce n'est pas illégitime. Mais vous devez savoir quelle part de votre produit repose dessus, et à quelles conditions cette licence peut prendre fin.

5. Ce qui n'est pas du code, mais fait partie du produit

La titularité ne s'arrête pas au dépôt Git. Sur un projet typique, il faut aussi traiter :

• le matériel de conception préparatoire, spécifications, schémas d'architecture, algorithmes rédigés, expressément visé par l'article XI.294 CDE ;
• les maquettes, l'interface, les icônes, les illustrations : régime du droit d'auteur de droit commun, éventuellement dessins et modèles ;
• la base de données et son contenu, qui relèvent d'un régime distinct (livre XI, titre 7, CDE) ;
• le nom du produit et le logo, qui relèvent du droit des marques et ne se cèdent pas par une clause logicielle ;
• les comptes et accès : nom de domaine, DNS, hébergement, jetons d'API, comptes de déploiement, store Apple et Google. Ils doivent être ouverts au nom de votre société, pas de celui du prestataire.

Un contrat qui ne cède que « le logiciel » laisse quatre de ces cinq lignes dehors.

Le code écrit avec une IA

C'est le sujet qui rend toutes les clauses ci-dessus insuffisantes si on n'y touche pas.

En 2026, une partie substantielle du code livré par un prestataire n'a pas été tapée par lui. Elle a été suggérée par un assistant intégré à son éditeur, générée à partir d'un prompt, puis relue, corrigée, intégrée. Votre contrat, lui, continue de supposer un auteur humain qui écrit ligne par ligne.

Le point dur : ce qui n'est pas protégé ne se cède pas

La protection d'un programme suppose l'originalité : une création intellectuelle propre à son auteur, qui suppose des choix libres et créatifs d'une personne physique (art. XI.295 CDE ; directive 2009/24/CE du 23 avril 2009). Le droit belge ne connaît aucune règle permettant à un sujet non humain d'être titulaire d'un droit d'auteur.

Conséquence, souvent contre-intuitive : du code purement généré par une machine, sans apport créatif humain, n'est en principe protégé par aucun droit d'auteur. Il n'y a donc rien à céder. Votre clause de cession, aussi bien rédigée soit-elle, s'applique à un objet vide.

Ce que vous perdez, ce n'est pas l'usage. Personne ne peut vous empêcher d'utiliser ce code : vous le détenez, il fonctionne, il est à vous de fait. Ce que vous perdez, c'est l'exclusivité. Vous ne pouvez interdire à personne de reproduire ce code s'il y accède. Votre prestataire peut le réutiliser chez votre concurrent, sauf si votre contrat le lui interdit par ailleurs.

Sur un produit dont la valeur est le service rendu, c'est supportable. Sur un produit dont la valeur est la technologie, c'est un trou dans l'actif.

La zone grise, honnêtement

Entre « écrit par un humain » et « généré par une machine », la frontière n'est pas nette. À ma connaissance, aucune décision belge ne tranche encore la question pour du code.

Ce qui se dessine dans les analyses disponibles :

• un prompt, même long et précis, ne suffit probablement pas à lui seul à fonder l'originalité du résultat ;
• en revanche, l'architecture d'ensemble, la sélection parmi plusieurs propositions, la réécriture, l'agencement des composants relèvent de choix humains susceptibles de porter l'originalité ;
• l'analyse est module par module, pas projet par projet. Un même dépôt peut contenir des fichiers protégés et des fichiers qui ne le sont pas.

Autrement dit : ce n'est pas « tout ou rien », mais vous ne saurez pas où se situe la ligne sans documentation du processus. Et c'est celui qui revendique le droit qui devra en établir l'originalité.

Les cinq clauses à ajouter

a. Déclaration d'usage. Le prestataire déclare les outils d'IA générative utilisés, sur quels modules, et dans quelle mesure. Pas pour interdire, interdire est irréaliste et invérifiable, mais pour savoir.

b. Traçabilité. Le prestataire conserve et remet les éléments permettant d'établir l'intervention humaine : historique de commits nominatif, journal des prompts et itérations pour les composants stratégiques, notes d'architecture. C'est ce dossier qu'un investisseur ou un acquéreur demandera. Il ne crée pas une originalité qui n'existe pas ; il rend démontrable celle qui existe.

c. Cession élargie et repli contractuel. La clause vise « les droits de propriété intellectuelle sur les livrables, dans la mesure où ils existent ». Pour le reste, elle organise ce que le droit d'auteur ne donne pas : exclusivité d'exploitation, interdiction de réutiliser le code livré pour un tiers, confidentialité du code source. Ajoutez un engagement de non-divulgation illimité dans le temps tant que le code n'est pas public. Le secret d'affaires devient ici votre protection principale, à condition que vous preniez réellement des mesures de confidentialité, ce qui en est la condition légale.

d. Garantie et indemnisation étendues à l'IA. Beaucoup de garanties de non-contrefaçon excluent, en petits caractères, ce qui provient d'outils tiers. Vérifiez que la garantie couvre expressément le code généré ou suggéré par une IA, et que l'indemnisation joue si un tiers revendique des droits.

e. Sort de vos entrées. Le prestataire donne votre code, vos spécifications, parfois vos données à un outil externe. Imposez la confidentialité des entrées et l'usage d'outils dont les conditions excluent la réutilisation des entrées pour l'entraînement. C'est un sujet contractuel, et aussi un sujet RGPD dès que des données personnelles circulent.

La contamination

Un assistant entraîné sur du code public peut restituer des fragments qui reproduisent du code existant, parfois sous licence copyleft. Le risque n'est pas théorique : il est faible ligne à ligne, réel à l'échelle d'un projet, et il se matérialise au pire moment, quand un acquéreur fait auditer votre dépôt.

Deux réflexes : faire tourner un scan de similarité et de licences avant chaque livraison majeure ; exiger que l'inventaire des dépendances (point 4 ci-dessus) mentionne explicitement les composants d'origine incertaine.

Ce que l'AI Act règle, et ce qu'il ne règle pas

Depuis le 2 août 2026, l'article 50 du règlement européen sur l'IA (règlement (UE) 2024/1689) est applicable. Il impose aux fournisseurs de systèmes d'IA générative de marquer leurs sorties dans un format lisible par machine. Un contenu généré artificiellement devient ainsi détectable. La Commission a publié le 10 juin 2026 un code de bonnes pratiques sur le marquage et l'étiquetage des contenus générés par IA. Le règlement (UE) 2026/1744 accorde un délai jusqu'au 2 décembre 2026 aux systèmes mis sur le marché avant le 2 août.

Deux précisions utiles pour un chef d'entreprise :

1. L'obligation de marquage pèse sur le fournisseur du modèle, pas sur vous ni sur votre développeur. Si vous appelez un modèle hébergé, ce n'est pas votre obligation.
2. Le texte, et donc le code, reste le point faible du marquage. Un fragment copié, reformaté ou retouché perd facilement sa trace. Ne comptez pas sur un filigrane pour savoir ce qui, dans votre dépôt, a été généré.

Surtout : l'article 50 est une règle de transparence. Il ne dit rien de la titularité. Un fragment marqué comme généré par IA n'en devient pas votre propriété. Un fragment non marqué n'en devient pas protégé. C'est votre contrat, et lui seul, qui organise ce que vous détenez.

Et si c'est votre propre salarié qui prompte

Même logique. La présomption de l'article XI.296 transfère des droits à l'employeur ; elle ne crée pas des droits qui n'existent pas. Si le code produit en interne n'est pas original, il n'est pas protégé, et le fait qu'il ait été produit par un salarié n'y change rien.

Ce qui protège votre produit dans ce cas, c'est la confidentialité, la politique interne d'usage des outils et la traçabilité. La présomption n'y suffit jamais.

Ce qui se passe si la clause manque

Rien, pendant longtemps. C'est ce qui rend le problème dangereux.

Puis un jour la question se pose. Une rupture avec le prestataire. Un investisseur qui demande la chaîne de titularité. Un acheteur, en due diligence, qui cherche à établir que la société cède bien ce qu'elle prétend céder. Une faillite du prestataire, et un curateur qui inventorie un actif incorporel dont vous pensiez être propriétaire.

À ce moment-là, la régularisation est possible : une convention de cession confirmative, signée par le développeur personne physique et par sa société, couvrant le passé. Mais vous négociez en position faible, avec quelqu'un qui sait exactement ce qu'il détient. Le coût n'est pas juridique. Il est commercial.

Et pour la part générée par IA, la régularisation ne règle rien : on ne cède pas ce qui n'est protégé par aucun droit. Là, le seul rattrapage possible est contractuel, exclusivité, non-réutilisation, confidentialité, et il suppose que l'autre partie ait encore une raison de signer.

Les dix lignes à chercher dans votre contrat

1. Cession expresse des droits patrimoniaux d'auteur, visant le logiciel et le code source.
2. Modes d'exploitation énumérés, durée, territoire.
3. Droit d'adapter, corriger, faire évoluer, par vous ou par un tiers.
4. Droit de sous-licencier et de céder sans accord préalable.
5. Intervention ou garantie de la personne physique qui a écrit le code.
6. Sources, documentation et scripts de build livrés effectivement, ou escrow.
7. Inventaire des composants tiers et de leurs licences.
8. Déclaration d'usage des outils d'IA et traçabilité de l'intervention humaine.
9. Garantie de non-contrefaçon couvrant expressément le code généré par IA, avec indemnisation.
10. Exclusivité, non-réutilisation et confidentialité, le filet quand le droit d'auteur ne joue pas.

Les questions à poser à votre IA

Avant de signer un contrat de développement, collez-le dans votre assistant et posez ces questions :

1. Ce contrat contient-il une cession expresse des droits patrimoniaux d'auteur sur le logiciel, et vise-t-il le code source ?
2. La cession couvre-t-elle le droit de modifier et de faire évoluer le code par un tiers, ainsi que le droit de sous-licencier et de céder ?
3. Qui signe la cession, et le contrat garantit-il que le signataire détient lui-même les droits qu'il cède ?
4. Le contrat traite-t-il des composants open source et des licences tierces ?
5. Le contrat dit-il quelque chose de l'usage d'outils d'IA générative, de la traçabilité du code produit et de la garantie qui s'y attache ?
6. Si une partie du code n'était protégée par aucun droit d'auteur, qu'est-ce qui, dans ce contrat, m'empêcherait de voir ce code réutilisé chez un concurrent ?
7. Qu'est-ce qui manque dans ce contrat par rapport à un contrat de développement complet en droit belge ?

La septième est la plus utile. C'est la seule qui demande ce qui n'est pas là.

La sixième est celle que presque personne ne pose.