Vous avez payé votre application web sur-mesure. Vous pensez donc en être propriétaire. Juridiquement, ce n'est pas automatique, et c'est l'une des surprises les plus coûteuses pour une PME qui veut changer de prestataire. Cet article explique les règles, la checklist contractuelle et les choix techniques qui garantissent que votre outil vous appartient vraiment. Cet article est une information générale, pas un conseil juridique : faites relire votre contrat par un avocat.
Ce que dit le droit
En France, une application web est protégée par le droit d'auteur. Quand elle est écrite par un salarié dans le cadre de ses fonctions, les droits patrimoniaux reviennent à l'employeur. Quand il est écrit par un prestataire extérieur, ils restent au prestataire, sauf cession écrite. Et cette cession doit être précise : chaque droit cédé (reproduction, modification, adaptation, distribution) doit être mentionné, avec son étendue, sa destination, le territoire et la durée. Une phrase vague du type « le client est propriétaire des livrables » peut ne pas suffire.
La checklist contractuelle
- Une clause de cession des droits détaillée, effective au paiement de chaque lot.
- La livraison du code source et de son historique (le dépôt complet, pas une archive figée).
- La documentation : installation, architecture, modèle de données.
- Les accès : hébergement, noms de domaine, services tiers, ouverts au nom de votre entreprise.
- La liste des composants tiers et de leurs licences, pour éviter une dépendance cachée.
- Une clause de réversibilité : assistance à la reprise par un autre prestataire, à un tarif fixé.
- L'export des données dans un format standard, à tout moment.
Pour une application web critique que le prestataire continue d'héberger, un dépôt du code auprès d'un tiers de confiance (séquestre) peut compléter le dispositif. Nos conseils pour lire un devis sont dans devis de développement d'applications web : le lire et le comparer.
La réversibilité se prépare aussi techniquement
Avoir le code ne suffit pas si personne d'autre ne sait le reprendre. Les choix qui facilitent la reprise :
- Des technologies répandues, pour lesquelles il est facile de trouver des développeurs (voir nos pages expertises).
- Une base de données standard, de préférence une base relationnelle documentée.
- Un déploiement automatisé (CI/CD), décrit dans le dépôt.
- Des tests automatisés, qui permettent à une nouvelle équipe de modifier sans casser.
- Un hébergement portable, par exemple en conteneurs, déplaçable d'un fournisseur à l'autre.
Le piège des plateformes propriétaires
Un outil construit sur une plateforme no-code ou un progiciel fortement personnalisé pose la même question sous une autre forme : vous possédez votre paramétrage, pas la plateforme. Si l'éditeur change ses prix ou ses conditions, vous suivez. C'est un critère à intégrer dans le choix, détaillé dans no-code ou sur-mesure et dans développement Odoo ou configuration.
Et après la livraison ?
La propriété n'empêche pas de confier la maintenance au prestataire d'origine ; elle vous laisse simplement le choix. Comptez en général 15 à 20 % du coût de développement par an pour la maintenance et les petites évolutions, comme l'explique l'article sur le coût total de possession. Pour reprendre un ancien outil dont vous n'avez pas le code, voir modernisation d'une application web existante.
Questions fréquentes
Qui est propriétaire du code d'une application web faite par un prestataire ?
Le prestataire, sauf cession écrite et détaillée des droits dans le contrat.
Qu'est-ce que la réversibilité ?
La capacité de reprendre application web et données avec une autre équipe sans repartir de zéro.
Le code est-il livré chez Trinity Studio ?
Oui : code, historique, documentation et accès, avec la cession des droits au contrat.
