Application sur mesure : à qui le code ?

La propriété du code d'une application sur mesure, je peux vous la résumer en une phrase : non, payer ne vous rend pas propriétaire. Tant qu'une cession écrite conforme à l'article L131-3 du Code de la propriété intellectuelle ne dit pas le contraire, le code reste à celui qui l'a écrit. Vous signez un devis pour une application, vous payez, vous recevez un outil qui tourne. Le jour où vous voulez changer de prestataire, héberger le projet ailleurs ou le confier à un autre développeur, vous découvrez ce que vous avez acheté. Souvent, c'est un droit d'usage. Pas la propriété du code. Ce malentendu, je le vois passer sur presque tous les projets qui arrivent chez moi après un premier prestataire. Voici comment trancher avant de signer.

En droit français, celui qui paie n'est pas propriétaire par défaut

Quand vous commandez un développement, le code appartient à celui qui l'a écrit tant qu'un contrat n'organise pas sa cession. Le Code de la propriété intellectuelle est clair. L'article L111-1 attache le droit d'auteur à l'auteur du seul fait de la création, sans aucune formalité. Payer une facture de prestation ne transfère aucun de ces droits.

Pour devenir propriétaire, il vous faut une cession écrite et explicite. L'article L131-3 impose un formalisme précis : chaque droit cédé doit être énuméré, avec son étendue, sa destination, sa durée et son territoire (source : Légifrance, Code de la propriété intellectuelle, articles L111-1 et L131-3). Une ligne vague du type « le client est propriétaire du livrable » ne coche pas toujours ces cases. Beaucoup de contrats restent muets là-dessus, et le silence profite à l'auteur du code, pas à vous.

Retenez ceci : sans clause de cession en bonne et due forme, vous avez financé un outil dont un autre garde la maîtrise juridique. C'est la première cause des mauvaises surprises que je constate en reprise de projet.

Les trois situations que je rencontre

Le SaaS locatif, no-code compris. Wix, Shopify, Bubble, un abonnement mensuel : c'est rapide et pratique, et vous louez. Vous ne détenez ni le code, ni l'infrastructure, ni toujours vos données dans un format réexploitable ailleurs. Le jour où vous arrêtez de payer, il ne reste rien de transférable.

L'agence à cession floue. Vous commandez du sur-mesure, mais le contrat ne dit rien de clair sur la propriété. L'agence garde parfois le dépôt « pour des raisons techniques », ou ne vous donne accès qu'à l'application en ligne. Vous avez payé du développement dédié et vous restez aussi dépendant qu'avec un abonnement.

Le sur-mesure cédé. Vous commandez, vous payez, le code vous est cédé à la livraison. Vous récupérez le dépôt complet. Vous pouvez le modifier, le redéployer, le confier à qui vous voulez. C'est la seule configuration où la propriété suit le paiement.

Posséder le code, ce que ça change au quotidien

La propriété ne se limite pas à une clause au contrat. Sur le terrain, elle vous donne trois libertés :

• Vous détenez le dépôt de code source complet, pas seulement l'application qui tourne.
• Vous pouvez le modifier, le copier, le redéployer, seul ou via un autre développeur.
• Vous cessez de dépendre du prestataire d'origine pour survivre. S'il augmente ses tarifs, ralentit ou ferme, votre outil continue de tourner.

Votre logiciel ne vous prend jamais en otage. C'est un point que je considère comme non négociable, y compris sur mes commandes clients de développement d'application métier avec code livré : quand je livre, vous repartez avec le dépôt Git et les droits qui vont avec.

Le lock-in a un coût, et il grimpe avec le temps

Le lock-in, c'est l'enfermement progressif : plus vous investissez dans un outil que vous ne possédez pas, plus il coûte cher d'en partir. Le no-code est le cas le plus sournois parce qu'il démarre presque gratuit. On construit son activité dessus, on bute sur une limite technique ou tarifaire, et migrer devient un chantier. J'ai chiffré ce mécanisme en détail dans un article dédié : le no-code, un lock-in par construction.

Deux chiffres pour situer. Côté no-code, les abonnements aux plateformes tournent autour de 1 300 à 2 000 € par an rien qu'en licences. Un montant qui s'accumule et finit par dépasser un développement sur-mesure sur trois à cinq ans (source : Nexaflow, analyse no-code vs développement sur mesure, 2025). Cet argent ne construit aucun actif à vous : c'est un loyer.

Le sujet est pris assez au sérieux pour faire désormais l'objet d'une régulation européenne. Le Data Act encadre les frais de changement de fournisseur cloud : plafonnés aux coûts réels dans un premier temps, puis interdits, ramenés à zéro à partir du 12 janvier 2027 (source : Commission européenne, Règlement UE 2023/2854). Le législateur reconnaît explicitement que l'enfermement technique freine l'économie. Raison de plus pour vérifier le vôtre en amont.

Comment vérifier avant de signer

Trois choses à demander noir sur blanc dans le devis ou le contrat.

1. La cession des droits. Le contrat doit stipuler que les droits de propriété intellectuelle du code vous sont cédés à la livraison, en général après paiement complet, avec le détail exigé par l'article L131-3.
2. L'accès au dépôt. Vous devez recevoir le code source, sur un dépôt dont vous êtes titulaire du compte, pas seulement l'application déployée.
3. La liberté d'hébergement et d'évolution. Rien ne doit vous obliger à rester chez le prestataire pour héberger l'outil ou le faire évoluer.

Si un prestataire devient évasif sur ces trois points, vous avez déjà votre réponse.

Ma règle chez Thillion

Chez moi, le principe est écrit dans le devis : le code vous appartient à 100 %, sans lock-in. Vous repartez avec le dépôt complet, libre de le confier à qui vous voulez. Je le pose d'autant plus volontiers que ça m'oblige à être bon. Si vous restez, c'est parce que le travail vous convient, jamais parce que vous êtes coincé. C'est la même logique qui me fait travailler à prix fixe signé d'avance : les règles sont claires des deux côtés dès le départ.

Une précision technique, par honnêteté. Du code livré vite ne vaut que s'il reste lisible et maintenable par le développeur suivant. Le code généré à la chaîne sans relecture porte en moyenne 1,7 fois plus de bugs que le code écrit et revu par un humain (source : Nexaflow, 2025). Posséder un dépôt illisible n'aide personne. La propriété a de la valeur quand elle porte sur du code propre.

Quand la location suffit

Tout ne mérite pas du sur-mesure possédé. Pour un besoin standard (une vitrine simple, une boutique classique, un outil de comptabilité générique), un SaaS ou un logiciel du marché fait très bien l'affaire : plus rapide à lancer, moins cher, entretenu par l'éditeur. La propriété devient décisive quand l'outil est stratégique pour vous. Quand votre process fait votre avantage, quand vous bâtissez dessus pour des années, quand en dépendre représente un risque pour la continuité de l'activité : là, détenir le code change tout.

Questions fréquentes

Payer un développement fait-il de moi le propriétaire du code ?

Non, pas automatiquement. En droit français, les droits d'auteur restent à celui qui a écrit le code tant qu'un contrat n'organise pas leur cession par écrit. Régler la facture ne transfère aucun droit de propriété intellectuelle sans clause dédiée.

Comment vérifier la cession dans mon contrat ?

Cherchez une clause qui cède les droits de propriété intellectuelle du code à la livraison, avec accès au dépôt source complet. L'article L131-3 du Code de la propriété intellectuelle exige que chaque droit soit énuméré, avec son étendue, sa durée et son territoire. Une formule floue comme « le client est propriétaire du livrable » ne suffit pas toujours.

Le no-code, est-ce du lock-in ?

Oui, par construction : vous bâtissez sur une plateforme que vous ne possédez pas et que vous louez au mois. C'est un bon choix pour tester une idée vite. Ça devient un risque le jour où votre activité en dépend et qu'une limite ou une hausse de prix vous force à migrer, sans repartir avec le code.

Que se passe-t-il si mon prestataire disparaît ?

Si vous détenez le dépôt de code et les droits, un autre développeur reprend le projet et rien ne s'arrête. Si vous n'avez qu'un accès à l'application déployée, vous risquez de tout perdre : le code, les données exploitables, la capacité de faire évoluer l'outil. C'est exactement le risque que la propriété du code supprime.

Vous lancez un projet et vous voulez être sûr d'en sortir propriétaire ? Décrivez votre projet et je vous réponds sous 48 h, ou réservez un appel de 30 min : je vous dis clairement ce que vous possédez à la fin. Pour aller plus loin, voici comment je conçois une application métier sur-mesure dont le code vous appartient.