À qui appartient le code de votre logiciel ?

C'est la question qu'on oublie de poser, et celle qui coûte le plus cher quand la relation se dégrade. Beaucoup de dirigeants découvrent, au moment de changer de prestataire, qu'ils n'ont jamais possédé le logiciel qu'ils ont financé.

Cet article donne des repères généraux et ne constitue pas un conseil juridique. Pour un contrat engageant, faites-le relire par un avocat spécialisé.

Le principe par défaut surprend

En droit français, l'auteur d'un logiciel en détient les droits patrimoniaux — sauf cession expresse et écrite. Autrement dit : sans clause de cession explicite dans votre contrat, financer le développement ne suffit pas à vous rendre propriétaire.

Une facture acquittée n'emporte pas cession. Une mention vague du type « le client dispose du logiciel » non plus. La cession doit préciser les droits cédés, leur étendue, leur durée et leur territoire.

Les trois modèles que vous rencontrerez

La cession complète

Le code vous appartient. Vous pouvez l'héberger où vous voulez, le faire évoluer par qui vous voulez, le revendre. C'est le modèle le plus protecteur, généralement associé aux développements intégraux.

La licence d'utilisation, ou le modèle SaaS

L'éditeur reste propriétaire du code et vous concède un droit d'usage, généralement contre un abonnement. C'est le modèle de la quasi-totalité des logiciels que vous utilisez déjà — et c'est parfaitement légitime : c'est précisément parce que le socle est mutualisé que vous ne payez pas son développement complet.

Transparence : c'est notre modèle. Nous éditons des SaaS, nous les hébergeons, et le code reste le nôtre. C'est ce qui nous permet de faire bénéficier chaque client des améliorations financées par les autres — et de facturer un ajustement plutôt qu'un développement complet.

Dans ce modèle, réclamer le code source n'aurait d'ailleurs pas grand sens : vous hériteriez d'une base que vous ne pourriez ni exploiter ni maintenir sans l'équipe qui l'a écrite. Ce qui vous protège est ailleurs, et c'est l'objet de la section suivante.

Le modèle mixte

C'est le plus courant dès qu'on part d'une base existante, et c'est souvent le plus honnête : le socle commun reste sous licence, la partie développée spécifiquement pour vous est cédée. Encore faut-il que le contrat dise clairement où passe la frontière.

La propriété ne suffit pas : exigez la réversibilité

Posséder le code ne sert à rien si vous ne pouvez pas l'exploiter. La vraie protection s'appelle la réversibilité, et elle se vérifie sur des points concrets :

• L'accès au dépôt de code. Idéalement sur un compte qui vous appartient, avec le prestataire comme contributeur — et non l'inverse.
• L'export de vos données. Dans un format standard et documenté, récupérable à tout moment sans intervention du prestataire.
• La documentation d'installation. De quoi permettre à une autre équipe de remettre le logiciel en service.
• La maîtrise des comptes d'hébergement. Hébergement, nom de domaine, base de données : ces comptes doivent être à votre nom, avec accès délégué au prestataire.
• Une clause de réversibilité. Qui prévoit explicitement l'accompagnement en cas de rupture, et son coût.

Le nom de domaine et les comptes d'hébergement sont le point le plus souvent négligé. Un logiciel dont vous possédez le code, mais hébergé sur le compte de quelqu'un d'autre, reste un logiciel dont vous dépendez.

Si votre prestataire est un éditeur SaaS

Les points d'accès au code ne s'appliquent pas, mais quatre garanties deviennent essentielles — et elles valent bien plus qu'une clause de cession théorique :

• L'export complet de vos données, à tout moment, sans frais ni préavis, dans un format ouvert et documenté — pas un PDF, pas une capture d'écran.
• Un délai de préavis écrit en cas d'arrêt du service, et la garantie de pouvoir exporter pendant toute cette période.
• Le sort de vos données à la fin du contrat : durée de conservation, puis suppression effective et attestée.
• Ce qui se passe si l'éditeur disparaît. Un engagement écrit — accès prolongé, export automatique, ou dépôt du code chez un tiers séquestre.

Les questions à poser avant de signer

Si l'on vous vend un développement :

• Le contrat contient-il une clause de cession des droits patrimoniaux ?
• Quelle part du code est cédée, quelle part reste sous licence ?
• Puis-je récupérer le code aujourd'hui, sans préavis et sans surcoût ?
• Les comptes d'hébergement et le domaine sont-ils à mon nom ?

Si l'on vous vend un abonnement :

• Puis-je exporter la totalité de mes données, seul, dès aujourd'hui ?
• Dans quel format, et avec quelle documentation ?
• Quel préavis en cas d'arrêt du service, de votre côté comme du mien ?
• Que devient ma base si je pars ? Sous combien de temps est-elle supprimée ?
• Que se passe-t-il si vous cessez votre activité ?

Un prestataire de bonne foi répond sans détour à ces six questions. L'embarras est en soi une réponse.

La vraie question n'est pas le code

Posséder le code source rassure, mais ne protège que si vous avez les moyens de l'exploiter. Beaucoup d'entreprises ont obtenu une cession de droits et se sont retrouvées, deux ans plus tard, avec une base qu'aucun prestataire ne voulait reprendre.

Ce qui vous protège réellement, dans les deux modèles, tient en une phrase : pouvoir partir avec vos données, à tout moment, sans avoir à demander la permission. C'est le seul engagement qui se vérifie en trente secondes — il suffit de demander un export aujourd'hui.

Un prestataire qui organise votre dépendance construit une relation où vous resterez par contrainte. Un prestataire qui vous laisse partir librement parie sur la qualité de son travail pour vous garder. La seconde posture revient bien moins cher sur cinq ans.