À qui appartient le code d'une application sur mesure ?

C'est la première question qu'on nous pose, et c'est la bonne. Pas « combien ça coûte » : « et après, il est à qui ? ». Elle vient presque toujours de quelqu'un qui a déjà payé une application, et qui a découvert le jour où il a voulu en changer que ce qu'il avait payé ne lui appartenait pas.

Ce que dit la loi, et ce que tout le monde suppose#

L'intuition est simple : j'ai payé, donc c'est à moi. Pour un meuble, c'est vrai. Pour un logiciel, non.

Un programme est protégé par le droit d'auteur. Celui qui l'écrit en détient les droits, et ces droits ne changent pas de main parce qu'une facture a été réglée. L'article L131-2 du Code de la propriété intellectuelle est explicite : les contrats par lesquels les droits d'auteur sont transmis « doivent être constatés par écrit ». Pas d'écrit, pas de transmission.

L'article L131-3 donne, lui, le niveau de précision attendu : chacun des droits cédés fait l'objet d'une mention distincte, et le domaine d'exploitation est délimité quant à son étendue, sa destination, son lieu et sa durée. Sa portée exacte pour un contrat de développement se discute encore devant les tribunaux — mais c'est la rédaction que suit la pratique, et c'est celle qu'il faut exiger. Une clause vague protège mal. L'absence de clause ne protège pas du tout.

Il y a une exception, et elle explique pourquoi la confusion est si répandue. L'article L113-9 prévoit que les logiciels écrits par un salarié dans l'exercice de ses fonctions appartiennent à son employeur, automatiquement. Beaucoup de dirigeants en déduisent que c'est vrai de tout développeur. Ce n'est vrai que du vôtre. Un prestataire, une agence, un indépendant ne sont pas des salariés : sans cession écrite, ils gardent leurs droits.

Ce que vous avez sans doute signé sans le voir#

Trois formulations reviennent, et aucune ne vous rend propriétaire.

1. « Le Client dispose d'un droit d'usage de la solution. » Un droit d'usage est une licence. Elle peut être retirée, limitée dans le temps, conditionnée au paiement d'un abonnement.
2. « Les livrables sont la propriété du Client. » Les livrables, ce sont souvent les écrans, les documents, les données — pas le code source, qui n'est alors mentionné nulle part.
3. Rien du tout. Le contrat décrit une prestation, un calendrier, un prix, et reste muet sur la propriété. Par défaut, elle reste au prestataire.

Propriété, accès, réversibilité : trois choses différentes#

La question « à qui appartient le code » en cache trois, qu'il faut séparer parce qu'on peut très bien avoir l'une sans les autres.

Un prestataire peut vous céder les droits et garder le dépôt chez lui. Vous pouvez avoir accès au dépôt sans détenir les droits. Et vous pouvez avoir les deux, et découvrir qu'il manque la moitié de ce qu'il faut pour que ça tourne ailleurs : la configuration, les secrets, la procédure de mise en service, la structure de la base.

Les trois se vérifient séparément. Elles se demandent séparément.

Les six questions à poser avant de signer#

Posez-les telles quelles, et demandez des réponses écrites. Un prestataire qui joue franc jeu répond en deux minutes.

1. Le contrat contient-il une cession de droits, au sens de l'article L131-3 ? Si oui, demandez à voir la clause. Elle doit nommer les droits cédés et leur portée.
2. À quel nom est le dépôt de code ? La bonne réponse est : au nom de votre entreprise, avec votre prestataire invité dessus — et pas l'inverse.
3. Et les services autour ? Hébergement, base de données, noms de domaine, boîtes mail, clés d'accès aux outils tiers : chacun a un compte, et chaque compte a un propriétaire. Il doit être vous.
4. Que se passe-t-il si vous arrêtez la collaboration ? Demandez ce qui vous est remis, sous quel délai, et sous quelle forme. Faites-le écrire.
5. Une reprise par une autre équipe est-elle documentée ? La question n'est pas « est-ce bien documenté », à quoi tout le monde répond oui. C'est : « un développeur extérieur peut-il installer et lancer le projet en suivant un fichier ? ».
6. Et les briques qui ne sont pas de vous ? Toute application s'appuie sur des bibliothèques externes. Demandez la liste et leurs licences : une brique sous licence restrictive peut contaminer l'ensemble.

On voulait juste ajouter un champ. On nous a répondu que ce n'était pas prévu au contrat, et qu'un autre prestataire ne pouvait pas y toucher.

Pourquoi nous avons tranché dans l'autre sens#

Chez Edenio, le client est propriétaire de son code. Le dépôt est à son nom, la cession est dans le contrat, et il peut à tout moment le faire auditer, le confier à quelqu'un d'autre, ou le reprendre en interne.

Ce n'est pas de la générosité, et ce n'est pas un argument de vente. C'est une contrainte qu'on s'impose, parce qu'elle change la façon de travailler. Quand un client peut partir à tout moment, on ne peut pas le retenir par le contrat : il faut le retenir par l'outil. Ça oblige à écrire du code qu'un autre peut reprendre, à documenter la mise en service pour de vrai, et à ne jamais cacher une dépendance derrière une boîte noire.

Le revers, il faut le dire : un outil dont vous êtes propriétaire est un outil dont vous êtes responsable. Il faudra le maintenir, mettre à jour ses briques, décider de ses évolutions. Nous le faisons tant que nous travaillons ensemble — mais c'est votre actif, pas le nôtre.

Comment nous le traitons#

Nous livrons le code source et les accès à l'hébergement, et le contrat le dit noir sur blanc avant la première ligne écrite. Vous pouvez partir avec, confier la suite à un autre prestataire, ou reprendre la maintenance en interne. Nous n'avons pas de licence à protéger : nous vendons du travail, pas un droit d'usage.

C'est le premier point que nous réglons en rendez-vous, avant de parler de fonctionnalités. Voir comment nous construisons une application — ce qui vous revient, ce qui reste chez vous, et ce qui arrive si vous nous arrêtez au bout de six mois.

À qui appartient le code : ce qu'il faut retenir#

Payer ne suffit pas. En droit français, la propriété d'un logiciel ne se transmet que par un écrit explicite et délimité ; l'automatisme de l'article L113-9 ne joue que pour les salariés, pas pour un prestataire.

Avant de signer, vérifiez trois choses séparément — la cession des droits, l'accès au dépôt et aux comptes, la réversibilité réelle — et faites répondre par écrit aux six questions ci-dessus. Si l'une d'elles gêne votre interlocuteur, vous venez de trouver ce qu'il fallait négocier.