Vous financez le développement d’une application métier : en êtes-vous pour autant propriétaire ? Pas automatiquement. En droit français, un logiciel est protégé par le droit d’auteur, et les droits appartiennent par défaut à celui qui l’a créé, c’est-à-dire à votre prestataire. Régler les factures vous donne le droit d’utiliser l’application, mais pas nécessairement celui de la modifier, de la confier à une autre équipe ou de la revendre.
Pour que le code source vous appartienne réellement, il faut une clause écrite de cession des droits dans le contrat, et il faut que vous disposiez concrètement du code et des accès techniques. Ces deux points se règlent avant la signature, en quelques lignes. Voici ce qu’il faut comprendre et vérifier, sans jargon juridique.
Pourquoi payer une application ne suffit pas à en être propriétaire
Un logiciel est considéré comme une œuvre de l’esprit, au même titre qu’un texte ou une photographie. Celui qui l’écrit en détient les droits dès sa création. Lorsque le développement est réalisé par les salariés d’une agence, ces droits reviennent à l’agence ; lorsqu’il est réalisé par un indépendant, ils lui reviennent personnellement.
Pour que ces droits passent chez vous, la loi exige une cession écrite et précise : elle doit indiquer quels droits sont transmis, pour quels usages, sur quel territoire et pour quelle durée. Une mention vague du type « le client est propriétaire des livrables » est fragile, et l’absence totale de clause joue en faveur du prestataire.
Prenons un exemple. Une entreprise de négoce fait développer un outil de gestion de ses commandes. Trois ans plus tard, elle souhaite changer de prestataire. Si le contrat ne prévoit rien, l’ancien prestataire peut légitimement refuser de remettre le code, ou conditionner cette remise à un paiement. L’entreprise se retrouve à négocier en position de faiblesse, pour un outil qu’elle a pourtant entièrement financé.
Ce que recouvre vraiment « le code source »
La question de la propriété ne se limite pas à un dossier de fichiers. Une application métier est un assemblage de plusieurs éléments dont le statut diffère.
Le code développé spécifiquement pour vous
C’est le cœur du sujet : les écrans, les règles de gestion, les traitements écrits pour votre projet. C’est sur cette partie que porte la cession des droits, et c’est elle que vous devez pouvoir récupérer intégralement.
Les composants open source et les briques du prestataire
Aucune application n’est écrite à partir de rien. Elle s’appuie sur des composants open source (framework, bibliothèques), qui restent soumis à leur propre licence et que personne ne peut vous céder. Elle peut aussi intégrer des briques réutilisables appartenant au prestataire, qu’il emploie d’un projet à l’autre. Pour ces dernières, la pratique courante est une licence d’utilisation étendue plutôt qu’une cession. L’essentiel est que le contrat liste ces éléments et vous garantisse le droit de continuer à les utiliser et à les faire évoluer, y compris avec un autre prestataire.
Vos données et votre documentation
Les données que vous saisissez dans l’application (clients, commandes, dossiers) sont les vôtres. Le contrat doit toutefois prévoir comment vous les récupérez : dans quel format, sous quel délai et à quel coût. Il en va de même pour la documentation technique, sans laquelle un code source est difficile à reprendre.
Cession ou licence : quelle différence concrète ?
Les deux formules existent et aucune n’est illégitime. Ce qui compte, c’est de savoir laquelle vous signez.
- La cession des droits : vous devenez titulaire des droits sur le code spécifique. Vous pouvez le modifier, le faire maintenir par qui vous voulez, le faire évoluer librement. C’est la formule la plus protectrice pour une application qui structure votre activité.
- La licence d’utilisation : le prestataire reste propriétaire et vous accorde un droit d’usage, plus ou moins large. Elle peut convenir si elle est sans limite de durée et vous autorise à modifier le code et à le confier à un tiers. Elle devient problématique lorsqu’elle vous lie au prestataire pour toute évolution.
- L’abonnement à une plateforme : vous louez un service, vous ne disposez pas du code. C’est le modèle des logiciels du marché, cohérent pour un outil standard, plus risqué pour un développement que vous avez financé en totalité.
Le moment de la cession mérite aussi votre attention. Il est fréquent, et raisonnable, qu’elle ne prenne effet qu’au paiement complet des factures : assurez-vous simplement que ce soit écrit.
Les clauses à vérifier avant de signer
Ces points se négocient facilement en amont, beaucoup plus difficilement une fois le projet livré. Vous pouvez les inscrire dès la rédaction de votre besoin : notre méthode pour rédiger le cahier des charges d’une webapp s’y prête bien.
| Clause | Ce qu’elle doit préciser | Le risque si elle manque |
|---|---|---|
| Cession des droits | Droits transmis (utilisation, modification, reproduction), usages, territoire, durée, moment de la cession | Le prestataire reste propriétaire du code |
| Remise du code source | Accès au dépôt de code pendant le projet, ou livraison à chaque version | Des droits sur le papier, mais aucun fichier en main |
| Composants tiers | Liste des composants open source et des briques du prestataire, avec leurs conditions d’usage | Une dépendance cachée qui bloque une reprise |
| Réversibilité | Restitution des données, documentation, assistance au transfert, délais et coût | Un changement de prestataire long et coûteux |
| Garantie d’originalité | Engagement du prestataire à détenir les droits sur ce qu’il vous cède | Un litige avec un tiers qui vous retombe dessus |
Ces repères ne remplacent pas un avis juridique : pour un projet engageant, faites relire le contrat par votre conseil habituel.
Au-delà du contrat : les accès à détenir vous-même
Être propriétaire en droit ne sert à rien si vous n’avez la main sur rien en pratique. Plusieurs éléments doivent être ouverts à votre nom, ou au minimum partagés avec vous :
- le nom de domaine, enregistré au nom de votre entreprise et non à celui du prestataire ;
- le compte d’hébergement, ou à défaut un accès administrateur et des sauvegardes récupérables ;
- le dépôt de code, auquel vous disposez d’un accès en lecture tout au long du projet ;
- les comptes de services tiers : envoi d’e-mails, paiement en ligne, cartographie, magasins d’applications ;
- les identifiants d’administration, conservés dans un endroit sûr et connus d’au moins deux personnes chez vous.
Ce point rejoint le choix de l’infrastructure : savoir où sont stockées vos données et qui en détient les clés fait partie des questions à poser lorsque vous choisissez l’hébergement de votre webapp. Chez Symbiose, nous recommandons de régler ces accès dès le démarrage du projet, quand tout le monde est disponible et de bonne volonté, plutôt qu’au moment d’une séparation.
Questions fréquentes
Le prestataire peut-il réutiliser le code pour d’autres clients ?
Cela dépend du contrat. Une cession exclusive le lui interdit pour le code spécifique à votre projet. En revanche, son savoir-faire et ses briques génériques restent les siens. Si votre application contient des règles métier qui font votre avantage concurrentiel, ajoutez une clause de confidentialité qui les couvre explicitement.
Mon contrat actuel ne dit rien : que faire ?
Ouvrez la discussion sans attendre un désaccord. Un avenant de cession peut être signé à tout moment, et la plupart des prestataires l’acceptent lorsque la relation est bonne. Demandez dans le même temps une copie du code et la liste des accès. Si vous envisagez de changer d’équipe, ces éléments sont le préalable à tout projet pour reprendre une application existante.
Être propriétaire du code dispense-t-il d’un contrat de maintenance ?
Non. La propriété vous donne la liberté de choisir qui intervient, pas la garantie que quelqu’un le fasse. Mises à jour de sécurité, sauvegardes et corrections restent à organiser : c’est l’objet de la maintenance d’une application web, à prévoir dès la mise en ligne.
Conclusion : la propriété se décide avant la première ligne de code
La propriété du code source n’est ni un détail juridique ni un sujet de défiance envers votre prestataire. C’est une condition de votre liberté future : faire évoluer l’outil, changer d’équipe, céder votre entreprise avec ses actifs. Elle repose sur trois éléments simples : une clause de cession écrite et précise, un accès effectif au code et aux comptes techniques, et une réversibilité organisée à l’avance.
Un prestataire sérieux aborde ces questions de lui-même et y répond clairement. Si vous préparez un projet d’application métier et souhaitez savoir ce que votre contrat devrait prévoir, contactez-nous pour en parler.