Vous avez payé pour votre site ou votre application. La facture est réglée, le projet est livré, tout fonctionne. Alors le code vous appartient, non ?
Pas forcément.
Ce que dit la loi
En France, un développeur — salarié à part, indépendant y compris — reste par défaut propriétaire des droits sur le code qu’il écrit, même après paiement. C’est l’article L131-3 du Code de la propriété intellectuelle : toute cession de droits doit être écrite et explicite, et préciser chaque droit cédé, son étendue, sa durée et son territoire d’exploitation.
Concrètement : payer une prestation ne suffit pas à transférer la propriété du code. Sans clause de cession claire dans le devis ou le contrat, vous avez payé un service, pas acheté un bien.
Pourquoi ça compte
Tant que tout va bien avec votre développeur, la question ne se pose jamais. Elle devient centrale le jour où :
- vous voulez faire évoluer votre site et votre développeur n’est plus disponible ou plus joignable,
- vous voulez comparer des devis pour une nouvelle fonctionnalité et personne d’autre ne peut reprendre le code sans tout redécouvrir,
- la relation se dégrade, et vous réalisez que vous n’avez ni les droits, ni la documentation pour partir ailleurs.
Dans ces situations, l’absence de cession de droits — ou l’absence de documentation exploitable par un tiers — transforme un simple changement de prestataire en blocage coûteux : il faut souvent tout refaire.
Deux choses à vérifier dès maintenant
La cession de droits. Relisez votre contrat ou votre devis. Une clause de cession de propriété intellectuelle doit y figurer explicitement, pas être sous-entendue par le fait que vous avez payé.
La documentation. Même avec les droits, un code sans documentation reste difficile à reprendre pour un autre développeur. Architecture technique, choix de stack, dépendances, accès aux hébergements et aux comptes tiers, logique métier : sans ce filet, chaque reprise de projet recommence en terrain inconnu.
Ce que je mets en place pour mes clients
Sur mes projets récents, dont un développement Flutter en cours, j’ai pris l’habitude de livrer une documentation technique complète en fin de mission, en plus de la cession de droits stipulée dans le contrat. L’objectif : que le client reste totalement libre — de continuer avec moi, de faire évoluer le projet en interne, ou de changer de développeur sans perdre six mois à tout redécouvrir.
C’est une question de sécurité, pas de défiance : un projet bien documenté et dont la propriété est claire est un projet dont vous restez maître, quoi qu’il arrive ensuite.
Et si c’est déjà trop tard ? Vous avez peut-être déjà le code en main, mais aucune documentation pour vous en servir sereinement — c’est très fréquent, surtout quand le projet a été livré sans y penser au moment de la mission. Bonne nouvelle : ce n’est pas irréversible. Je peux reprendre un projet existant, l’analyser et produire cette documentation a posteriori, même si je ne suis pas le développeur d’origine. Ce n’est ni un nouveau développement, ni une reprise de projet — juste le filet de sécurité qui aurait dû être livré avec le code. (À condition que votre contrat initial n’interdise pas explicitement toute intervention d’un tiers sur le code — un point qu’on vérifie ensemble avant de démarrer.)
Que vous démarriez un projet ou que vous ayez déjà du code sans documentation, je peux faire un point rapide avec vous sur ce que vous avez — et ce qu’il vous manque — pour rester libre de vos choix.
