Aller au contenu
METHODE 9 min

Qui est propriétaire du code de votre logiciel sur mesure ? La réponse n'est pas celle que vous croyez

Payer le développement ne vous rend pas propriétaire du code. En droit français, la cession doit être écrite. Les quatre formulations à vérifier avant de signer, et le test qui révèle tout.

Par Laurent Tulpan

C’est la question qu’on ne pose jamais au bon moment. On la pose à la fin, quand la relation avec le prestataire se dégrade ou qu’on veut confier l’évolution à quelqu’un d’autre. À ce moment-là, il est trop tard : ce qui est écrit dans le contrat est écrit.

Et ce qui est écrit, très souvent, ne dit rien.

Le point de départ que presque personne ne connaît

Payer le développement d’un logiciel ne vous en rend pas propriétaire.

En droit français, les droits d’auteur sur un logiciel naissent chez celui qui l’a écrit, ou chez son employeur s’il l’a écrit dans le cadre de son emploi. Ils ne se transmettent pas par le seul fait du paiement. Pour qu’ils vous reviennent, la cession doit être écrite et délimitée : quels droits, pour quels usages, sur quel territoire, pour quelle durée.

Un contrat de prestation qui facture des jours de développement et ne mentionne pas la propriété intellectuelle ne vous a rien cédé. Vous avez payé un travail, vous détenez un exécutable, et l’étendue de ce que vous pouvez en faire se discutera le jour où ça deviendra important.

Ce n’est pas une chicane de juriste. C’est le régime par défaut, et il joue contre l’acheteur qui ne l’a pas vu.

Les quatre niveaux, du pire au bon

Niveau 1 : le contrat est muet. Le cas le plus fréquent chez les petites structures. Il n’y a pas de mauvaise intention, il y a un modèle de devis qui n’a jamais été relu par personne. Le résultat est le même qu’une mauvaise intention : rien ne vous est acquis.

Niveau 2 : un droit d’usage. Le contrat vous autorise à utiliser le logiciel. Souvent « dans le cadre de votre activité », parfois « pendant la durée du contrat ». Vous pouvez vous en servir, vous ne pouvez pas nécessairement le faire modifier par un tiers, ni le déployer ailleurs. C’est la formulation qui ressemble le plus à de la propriété sans en être, et c’est la plus répandue dans les contrats bien rédigés du point de vue du prestataire.

Niveau 3 : une cession partielle. Le code spécifique à votre projet vous revient, le socle technique réutilisable du prestataire reste à lui, sous licence. C’est souvent la vérité du terrain, et c’est parfaitement acceptable, à condition que la frontière soit écrite. Un prestataire qui a construit un socle à ses frais sur dix missions ne peut pas vous le céder sans se dépouiller. Ce qui n’est pas acceptable, c’est de découvrir cette frontière au moment du départ, et de constater qu’elle passe par le milieu de ce qui vous est utile.

Niveau 4 : la cession pleine à la livraison et au paiement intégral. Le code source, les contenus produits, les accès aux outils tiers. C’est ce qu’on écrit dans nos contrats, et ce n’est pas une générosité : c’est la contrepartie logique d’un engagement au forfait. Si on vend un résultat et non du temps, le résultat vous appartient.

Les quatre lignes à vérifier avant de signer

Aucune ne demande d’être juriste. Il suffit de chercher les mots.

1. Le mot « cession », et pas « licence » ni « droit d’usage ». Cherchez-le littéralement dans le document. S’il n’y est pas, la propriété ne vous est pas transférée, quelle que soit la chaleur de la relation commerciale.

2. Ce qui déclenche la cession. « À la livraison et au paiement intégral » est une formulation saine. Elle protège les deux parties : le prestataire n’a pas cédé un travail impayé, vous n’avez pas payé un travail non cédé.

3. Le périmètre de ce qui est cédé. Le code, mais aussi : les scripts de déploiement, la documentation technique, les jeux de données de test, les maquettes, et les accès aux services tiers ouverts pour votre projet. Un code source sans ses scripts de déploiement est un puzzle sans la boîte. C’est le manque le plus courant, et le plus handicapant en pratique.

4. La garantie d’éviction. Le prestataire garantit que les livrables ne violent pas les droits d’un tiers. C’est cette clause, et non un débat sur les méthodes de production, qui vous protège contre une brique intégrée sans licence compatible.

Le test qui révèle tout, et qui prend une minute

Posez cette question, à l’oral, avant de signer :

« Si dans deux ans je veux confier les évolutions à une autre équipe, qu’est-ce que vous me remettez, et en combien de temps ? »

Les réponses se classent d’elles-mêmes.

Un prestataire qui répond « le dépôt, la documentation d’exploitation, les accès, et on prévoit une passation de quelques jours » a déjà fait cette opération et l’a organisée. Un prestataire qui répond « aucun souci, on est très ouverts » sans détailler ne l’a jamais fait. Un prestataire que la question met mal à l’aise vous a donné l’information la plus utile de tout le rendez-vous.

La question ne vise pas à le piéger. Elle vise à savoir si la réversibilité existe comme processus ou comme intention.

Ce qu’on met dans nos contrats, et pourquoi

À la livraison et au paiement intégral, le client devient propriétaire du code source produit pour son projet, des contenus rédigés et des accès aux outils tiers. On conserve la paternité du travail et la possibilité de citer le client comme référence, sauf clause contraire. Le client peut reprendre la main ou changer de prestataire à tout moment, et une passation documentée est fournie si la collaboration s’interrompt.

La raison n’est pas éthique, elle est structurelle. Un modèle économique qui repose sur la dépendance du client pousse à livrer du code que personne d’autre ne peut reprendre. Ce n’est pas une intention, c’est une pente. En cédant tout, on se prive de cette pente : la seule façon de garder un client est qu’il ait envie de revenir.

Mesuré en juillet 2026, sur toutes les missions menées depuis 2019 : aucun client n’a eu besoin de nous rappeler en urgence après une passation. C’est un chiffre que nous produisons nous-mêmes, donc à prendre comme une déclaration dont nous sommes comptables, pas comme un audit. C’est aussi celui sur lequel nous préférerions être interrogés lors d’un appel de référence.

Les clauses correspondantes sont fournies déjà rédigées dans notre modèle de cahier des charges, pour que vous puissiez les opposer à n’importe quel prestataire, y compris à nous.

Pour aller plus loin

Questions fréquentes

On répond sans détour.

  • Si je paie le développement, le code m'appartient automatiquement ?

    Non. En droit français, les droits d'auteur naissent chez l'auteur, c'est-à-dire chez le développeur ou son employeur, et leur cession doit être écrite et délimitée pour être valable. Un contrat de prestation qui ne dit rien de la propriété intellectuelle vous laisse donc, au mieux, un droit d'usage implicite dont l'étendue se discutera au moment où vous voudrez partir. Payer n'est pas acquérir. Ce n'est pas une subtilité de juriste, c'est la règle par défaut.

  • Quelle est la différence entre un droit d'usage et la propriété ?

    Un droit d'usage vous autorise à utiliser le logiciel, souvent tant que la relation dure. La propriété vous autorise à le faire modifier par quelqu'un d'autre, à le déployer où vous voulez et à le vendre s'il fait partie de votre activité. La nuance est invisible pendant que tout va bien, et décisive le jour où vous changez de prestataire. C'est exactement pour cela qu'elle est souvent laissée dans le flou.

  • Un prestataire peut-il refuser de céder le code ?

    Il peut, et parfois pour de bonnes raisons : s'il a intégré des briques réutilisables développées à ses frais sur d'autres missions, il ne peut pas vous les céder sans se dépouiller. Ce cas est légitime et se traite en distinguant ce qui est spécifique à votre projet, qui vous revient, et ce qui relève de son socle, qui reste à lui sous licence. Ce qui n'est pas légitime, c'est de refuser sans expliquer, ou de découvrir cette distinction au moment du départ.

  • Et le code généré par une IA, à qui appartient-il ?

    La question est réelle et le droit n'est pas entièrement stabilisé, mais elle change moins de choses qu'on le croit sur le plan contractuel. Ce qui vous protège reste identique : que le prestataire s'engage à vous céder l'ensemble des droits sur les livrables, quelle que soit la manière dont ils ont été produits, et qu'il garantisse qu'ils ne violent pas les droits d'un tiers. Cette garantie est la clause qui compte, et elle vaut pour du code écrit à la main comme pour du code assisté.

On en parle

Vous voulez tester notre méthode ? Feuille de route à 2 à 3 k€ HT.

Deux à cinq jours pour cadrer une décision tech. Livrable exploitable même sans suite. Déduit si vous continuez avec nous.