Vous financez le développement d'une application. Des mois de travail, un budget engagé, un outil qui devient central pour votre activité. Une question mérite d'être posée avant de signer : à qui appartient le code ? La réponse paraît évidente. Elle ne l'est pas.
En droit français, payer un développement ne transfère pas automatiquement la propriété du code. Sans clause de cession écrite, les droits patrimoniaux restent en principe à celui qui l'a écrit. Vous détenez alors un droit d'utiliser l'outil, pas l'outil lui-même. Le principe est contre-intuitif, il est pourtant central : vous payez la prestation, pas les droits sur l'œuvre. Et cette nuance définit tout le rapport de force avec votre prestataire.
Propriété du code : de quoi parle-t-on exactement
La formule recouvre trois niveaux distincts. Les confondre est la source des mauvaises surprises.
- L'accès au code source : vous pouvez lire et récupérer les fichiers qui font tourner votre application, à tout moment, pas seulement en fin de projet.
- La cession des droits : le contrat vous transfère par écrit les droits patrimoniaux sur le code développé pour vous. C'est elle qui fait de vous le propriétaire.
- La maîtrise des comptes : hébergement, nom de domaine, base de données et dépôt de code sont ouverts à votre nom, pas à celui du prestataire.
Les trois sont nécessaires. Un code cédé mais hébergé sur les comptes du prestataire reste un code sous contrôle. Un accès au dépôt sans cession écrite reste une tolérance révocable.
Ce que la propriété change, concrètement
La propriété du code n'est pas une position de principe. Elle ouvre quatre portes très concrètes.
- Changer de prestataire. Si la relation se dégrade, si les délais dérapent ou si les tarifs montent, vous confiez le code à une autre équipe et le projet continue. Sans le code, changer signifie tout redévelopper.
- Faire auditer. Un développeur indépendant peut examiner la qualité du code, la sécurité, les dépendances. C'est votre garde-fou : un prestataire qui sait que son travail peut être relu par un tiers travaille autrement.
- Internaliser. Le jour où votre outil justifie un développeur en interne, il reprend un code qui vous appartient. La prestation devient un actif, pas un abonnement déguisé.
- Valoriser l'entreprise. En cas de levée de fonds ou de cession, un logiciel central pour l'activité dont vous ne détenez pas les droits est un problème que les acquéreurs repèrent vite. Un code détenu en propre est un actif ; un simple droit d'usage se renégocie.
Les verrous à repérer avant de signer
L'enfermement prend rarement la forme d'un refus frontal. Il se loge dans les détails du contrat ou de l'architecture.
- Le code non livré : vous recevez un site ou une application en ligne, jamais les sources. La livraison se limite au résultat visible.
- La licence d'utilisation : le contrat vous « concède un droit d'usage » au lieu de céder les droits. Vous êtes locataire de votre propre outil.
- L'hébergement captif : serveurs, base de données et nom de domaine sont au nom du prestataire. Partir suppose sa coopération.
- La plateforme propriétaire : l'outil est construit sur un système fermé que seul le prestataire exploite. Le code existe, mais il ne tourne nulle part ailleurs.
- La réversibilité absente : rien ne décrit ce qui se passe si la collaboration s'arrête, ni sous quelle forme les éléments vous sont remis.
Les questions à poser, à n'importe quel prestataire
Posez-les avant de signer, par écrit, et demandez des réponses écrites. Elles valent pour tout le monde, WePulse compris.
- Le contrat prévoit-il une cession écrite des droits sur le code développé pour moi ?
- Aurai-je un accès permanent au dépôt de code pendant le projet, et pas seulement une archive à la fin ?
- L'hébergement, le nom de domaine et la base de données seront-ils ouverts sur mes comptes ?
- Quelles briques restent votre propriété ou celle d'un tiers, et sous quelle licence ?
- Si nous arrêtons de travailler ensemble, que me remettez-vous, sous quelle forme et à quel coût ?
- Une autre équipe pourrait-elle reprendre le projet avec ce que vous me livrez, documentation comprise ?
Comment lire les réponses
Un prestataire sérieux répond précisément, parce qu'il a déjà réglé ces questions dans son contrat type. La cession y figure, l'accès au dépôt est la norme, les comptes sont ouverts à votre nom. Méfiez-vous des réponses qui déplacent le sujet : « personne ne demande ça », « c'est notre framework interne », « vous n'en aurez pas besoin, on s'occupe de tout ». Aucune n'est une raison de renoncer à la propriété.
Soyez simplement précis sur le périmètre. Personne ne peut vous céder les briques open source qu'utilise votre application, ni le socle générique qu'un studio réutilise d'un projet à l'autre. Ce qui doit vous revenir, c'est le code développé pour vous, avec le droit de l'exploiter, de le modifier et de le confier à qui vous voulez.
La position de WePulse
Chez WePulse, la réponse tient en une phrase : le code vous appartient. Pas un droit d'usage, une propriété prévue au contrat. Vous pouvez le faire auditer, le confier à une autre équipe ou l'internaliser quand vous le décidez. Nous préférons être choisis pour la qualité du travail, pas retenus par un verrou.
Avant de signer votre prochain contrat de développement, reprenez la liste de questions ci-dessus. Un simple échange suffit souvent à savoir si vous achetez un actif ou si vous louez une dépendance.