Propriété du code, documentation, réversibilité : ce qu'il faut exiger

En résumé. Vous avez payé 30 000 € un agent IA. Sans clause de cession écrite et détaillée, vous n’en êtes pas propriétaire, et ce n’est pas une subtilité de juriste : c’est la règle par défaut du droit français. Le prestataire indépendant conserve les droits sur son code sauf cession expresse. La mention « tous droits cédés » ne suffit pas, la jurisprudence la juge inopérante. Trois exigences à poser avant de signer : une cession qui liste chaque droit avec son étendue et sa durée, une documentation qui permette à un autre développeur de reprendre, et vos propres accès à l’infrastructure. Le seul test qui vaut : combien de temps et combien d’euros pour repartir sans votre prestataire.

Ce que dit le droit, et ce que croient les dirigeants

La croyance générale : j’ai payé le développement, le code est à moi.

Le droit dit l’inverse. Le code source est une œuvre protégée par le droit d’auteur, et l’auteur est celui qui l’écrit. Payer une prestation rémunère un service, pas un transfert de propriété intellectuelle. Un développeur indépendant, une agence ou une ESN conserve donc les droits sur le code qu’il a produit, sauf cession expresse et écrite à votre profit.

L’article L131-3 du Code de la propriété intellectuelle pose la condition, dans une formulation qui n’a pas bougé depuis 1992 :

« 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. »

Quatre exigences dans une seule phrase : chaque droit mentionné distinctement, l’étendue délimitée, la destination précisée, le lieu et la durée fixés. Une clause qui n’en couvre que deux est fragile.

Une confusion fréquente mérite d’être levée. L’article L113-9 du même code prévoit bien une dévolution automatique des droits patrimoniaux sur un logiciel à l’employeur. Mais il ne régit que la relation employeur-salarié : entre un prestataire externe et son client, il ne produit aucun effet. Le développeur salarié de votre entreprise et le développeur que vous facturez ne sont pas dans la même situation juridique, et beaucoup de dirigeants raisonnent comme si c’était le cas.

La clause qui ne vaut rien

« Le prestataire cède au client tous les droits sur les développements réalisés. »

Cette phrase figure dans un grand nombre de contrats de prestation. Elle ne remplit aucune des conditions de l’article L131-3 : aucun droit n’est mentionné distinctement, aucune étendue n’est délimitée, aucune durée n’est fixée. La jurisprudence considère la formule globale « tous droits cédés » comme inopérante.

Une clause utile ressemble plutôt à ceci, dans son principe. Elle énumère les droits cédés, à savoir la reproduction, la représentation, l’adaptation, la modification, la traduction et la distribution du code. Elle précise que la cession vaut pour tous supports et tous usages internes de l’entreprise, y compris l’exploitation commerciale si c’est le cas. Elle fixe la durée, généralement la durée légale de protection, et le territoire, généralement le monde entier. Elle indique la rémunération correspondante, ne serait-ce qu’en précisant qu’elle est incluse dans le prix de la prestation.

Ce n’est pas un article de droit et je ne suis pas juriste : faites relire la clause par un avocat si l’enjeu le justifie. Ce qui relève du bon sens du dirigeant, en revanche, c’est de vérifier que la clause existe et qu’elle est détaillée, et non de se satisfaire d’une ligne générique.

Le cas particulier des briques réutilisables

Un point d’honnêteté que peu de prestataires abordent spontanément, et qu’il vaut mieux régler à la signature qu’à la sortie.

Aucun développeur ne repart de zéro. Sur un projet d’agent IA, une partie du code vient de bibliothèques open source, une autre de composants que le prestataire réutilise d’un client à l’autre : connecteurs, utilitaires, structures de projet. Il ne vous cédera pas la propriété exclusive de ces briques, et exiger le contraire est déraisonnable.

La formulation qui protège les deux parties distingue deux ensembles. Les développements spécifiques, ceux qui portent votre métier et vos règles, vous sont cédés en pleine propriété. Les composants génériques préexistants font l’objet d’une licence perpétuelle, irrévocable, gratuite et transférable, qui vous autorise à les utiliser, à les modifier et à les faire modifier par un tiers.

Sans cette licence sur les briques génériques, vous êtes propriétaire d’un code que vous ne pouvez pas faire tourner. C’est le piège le plus élégant du secteur, et il est parfaitement légal.

Les deux exigences que la propriété ne couvre pas

Être propriétaire du code ne suffit pas. Deux éléments décident de votre autonomie réelle.

La documentation. Un dépôt de code sans explication est une archive, pas un actif. Le critère n’est pas le nombre de pages produites, c’est le résultat : un développeur qui ne connaît pas le projet doit pouvoir le reprendre en un temps borné. Exigez au minimum une description de l’architecture, la liste des dépendances et des services externes utilisés, la procédure d’installation et de mise en service, les variables de configuration et leur rôle, la manière de lancer les tests, et les décisions techniques structurantes avec leur justification.

Les accès. Le code vous appartient, la machine sur laquelle il tourne aussi. Les comptes chez les fournisseurs de modèles, l’hébergement, les bases de données, les clés d’API, le nom de domaine : tout doit être ouvert à votre nom, avec vous en administrateur, pas au nom du prestataire avec un accès invité pour vous. Cette configuration s’installe en une journée au démarrage du projet et devient un rapport de force au moment de partir.

Un projet où le prestataire détient les comptes est un projet où votre coût de sortie est indéterminé, même avec la meilleure clause de cession du monde.

Le test de réversibilité

Une seule question mesure votre situation réelle, et elle se pose avant de signer, pas après.

Si je remercie ce prestataire demain matin, combien de temps et combien d’euros pour qu’un autre développeur reprenne la main ?

Une réponse chiffrée engage. Une réponse floue vous informe déjà.

Voici la grille que j’utilise pour situer un projet existant lors d’un second avis.

Signal	Situation
Vous avez le code, la documentation et les accès, et un tiers estime la reprise à moins de deux semaines	Sain
Vous avez le code et les accès, mais aucune documentation	Reprise possible, comptez trois à six semaines de rétro-ingénierie
Le code tourne sur l’infrastructure du prestataire, avec ses comptes	Coût de sortie non maîtrisé, à corriger sans attendre
Le prestataire refuse de chiffrer le coût de sortie	Traitez la réponse comme l’information qu’elle est

Le deuxième cas est le plus fréquent, et de loin. Le code existe, il fonctionne, personne ne sait pourquoi. Ce n’est pas de la malveillance, c’est de la documentation reportée à plus tard pendant dix-huit mois.

Ce que je m’engage à fournir

Autant écrire mes propres conditions, puisque j’attends d’un lecteur qu’il les exige de son prestataire.

Le code vous appartient, avec une cession détaillée au contrat. La documentation technique est un livrable au même titre que le code, pas une option à budgéter en fin de projet. Les accès à l’infrastructure et aux comptes fournisseurs sont ouverts à votre nom dès le premier jour. En cas d’arrêt du contrat, le coût de sortie est de zéro euro. Et la reprise en main par un autre développeur est calibrée pour tenir en une semaine, ce qui est le seul engagement de cette liste qui se vérifie objectivement : il suffit de le tester.

Ces conditions ne sont pas une générosité. C’est ce qu’un développeur indépendant peut offrir précisément parce qu’il ne vit pas de l’enfermement de ses clients, là où un modèle économique fondé sur une plateforme propriétaire a une raison structurelle de faire autrement.

Ce qui est négociable, et ce qui ne l’est pas

Trois points se négocient sans drame : le périmètre exact de la cession, l’étendue de la documentation, le délai de restitution des accès en cas de rupture. Un prestataire sérieux discutera ces points.

Trois points ne se négocient pas, et un refus sur l’un d’eux devrait arrêter la discussion. L’existence d’une clause de cession détaillée, et non générique. Une licence sur les composants génériques réutilisés, sans quoi la cession est creuse. Vos accès administrateur sur votre propre infrastructure.

Un cas particulier mérite d’être signalé, parce qu’il n’est pas illégitime. Certains prestataires vendent une plateforme sous licence plutôt qu’un développement sur mesure. Le code ne vous appartient alors pas, par construction, et c’est cohérent avec le modèle. Ce qui pose problème n’est pas ce choix, c’est de vendre du sur-mesure au prix du sur-mesure en gardant la propriété d’une plateforme. Demandez lequel des deux vous achetez ; la réponse doit figurer au contrat. De mon côté elle est écrite d’avance : le code et la documentation vous appartiennent, et un autre développeur reprend la main en une semaine, sans rien à payer.

---

Références juridiques vérifiées le 13 août 2026 : article L131-3 et article L113-9 du Code de la propriété intellectuelle. Cet article décrit des principes généraux et ne constitue pas un conseil juridique : faites relire vos clauses par un avocat lorsque l’enjeu le justifie.