C'est l'un des pièges juridiques les plus contre-intuitifs de la commande informatique : en droit français, payer intégralement le développement d'un logiciel ne vous en transfère pas la propriété intellectuelle. Le code de la propriété intellectuelle protège le logiciel comme une œuvre de l'esprit, et ses droits naissent sur la tête de l'auteur — en pratique, du prestataire dont les salariés l'ont écrit — sans que l'existence d'un contrat de commande n'y change rien par elle-même. Sans clause de cession rédigée dans les formes, votre entreprise peut se retrouver, après avoir payé des dizaines de milliers d'euros, simple utilisatrice tolérée d'un logiciel qu'elle croyait sien : impossible de le faire évoluer par un tiers, de le revendre, parfois même de le migrer sereinement. Le sujet prend une acuité particulière dans un contexte d'externalisation, y compris nearshore : la distance rend les malentendus plus faciles et les recours plus lourds. La bonne nouvelle, c'est que le dispositif de protection est bien connu et tient en quelques clauses à exiger avant de signer. CRYSTAL IT, éditeur de logiciels basé à Rabat qui développe pour des clients français (nos services d'offshoring informatique), a fait de la cession claire des droits un standard contractuel : voici ce que vous devez savoir et exiger, que vous travailliez avec nous ou avec quiconque.
Pourquoi payer ne suffit pas : ce que dit le droit français
Le logiciel est protégé par le droit d'auteur. L'article L111-1 du code de la propriété intellectuelle pose que l'auteur d'une œuvre de l'esprit jouit sur elle d'un droit de propriété exclusif du seul fait de sa création — et précise que l'existence d'un contrat de louage d'ouvrage ou de service n'emporte par elle-même aucune dérogation à cette règle. Traduction concrète : commander et payer un développement ne vous transfère pas les droits d'auteur sur le code produit. Pour le logiciel écrit par des salariés, l'article L113-9 prévoit une dévolution automatique des droits patrimoniaux à l'employeur : les droits sur le code écrit par les développeurs salariés de votre prestataire appartiennent donc… à votre prestataire, pas à vous.
Ce que recouvrent ces droits patrimoniaux est défini pour le logiciel à l'article L122-6 : reproduction, modification, adaptation, mise sur le marché. Sans cession, chacun de ces actes suppose en principe l'autorisation du titulaire. Concrètement, un client sans clause de cession peut se voir opposer l'impossibilité de confier la maintenance à un autre prestataire (la modification est un droit réservé), de réutiliser le code dans un autre produit, ou de valoriser le logiciel lors d'une cession d'entreprise. Ce n'est pas un scénario d'école : c'est l'arme de négociation classique d'un prestataire en fin de relation conflictuelle. La seule protection est une cession écrite, explicite et conforme aux exigences de forme du code — c'est l'objet de la section suivante.
- Article L111-1 du CPI : les droits naissent chez l'auteur, et le contrat de commande n'y déroge pas par lui-même.
- Article L113-9 : les droits sur le logiciel créé par des salariés sont dévolus à l'employeur — donc au prestataire, pas au client.
- Article L122-6 : reproduction, modification, adaptation et mise sur le marché sont des droits réservés au titulaire.
- Sans cession écrite, le client paie un logiciel dont il n'est que l'utilisateur — avec le prestataire en position de force à chaque renégociation.
La clause de cession : les mentions sans lesquelles elle ne vaut rien
Le droit français est formaliste sur la transmission des droits d'auteur, et ce formalisme protège en réalité le client autant que l'auteur : une clause vague se retourne contre celui qui l'invoque. L'article L131-3 du CPI exige que la transmission mentionne distinctement chacun des droits cédés, et que le domaine d'exploitation des droits cédés soit délimité quant à son étendue, sa destination, son lieu et sa durée. Une formule du type « le prestataire cède tous ses droits au client » est dangereusement insuffisante : mal rédigée, la cession peut être interprétée restrictivement, voire privée d'effet sur les droits mal désignés.
Une clause robuste énumère donc les droits cédés (reproduction, représentation, modification, adaptation, traduction, mise sur le marché, sur tous supports), précise la destination (tous usages, y compris commerciaux, avec droit de céder et de sous-licencier), le territoire (le monde entier), la durée (toute la durée légale de protection des droits) et le moment du transfert — idéalement au fur et à mesure du développement ou au plus tard au paiement de chaque livrable, plutôt qu'à la toute fin du projet. Précisez aussi l'assiette : code source et objet, scripts, schémas de bases de données, documentation, maquettes et éléments graphiques. Deux points de vigilance complémentaires : le droit moral de l'auteur est incessible en droit français (il subsiste, mais son exercice est très limité en matière de logiciel), et si le prestataire sous-traite, exigez qu'il garantisse détenir les droits de ses propres sous-traitants — une chaîne de cession ne vaut que par son maillon le plus faible.
- Article L131-3 du CPI : chaque droit cédé doit être mentionné distinctement, avec étendue, destination, lieu et durée.
- « Cession de tous droits » sans détail = clause fragile, d'interprétation restrictive en cas de litige.
- Cession au fil de l'eau ou à chaque livrable payé, jamais seulement à la fin du projet.
- Assiette complète : sources, scripts, schémas, documentation, maquettes — pas seulement « le logiciel ».
- Chaîne de cession garantie : le prestataire doit détenir les droits de ses salariés et sous-traitants pour pouvoir vous les céder.
Cession exclusive, licence, socle réutilisable : choisir le bon montage
La cession exclusive de tout le code n'est pas toujours le bon montage, ni même toujours possible. La plupart des prestataires sérieux capitalisent sur des briques génériques — frameworks internes, composants techniques, générateurs — qu'ils réutilisent de projet en projet et ne peuvent céder exclusivement à un client sans se déposséder. Le montage standard distingue donc trois couches : les développements spécifiques réalisés pour vous, cédés en pleine propriété ; le socle générique du prestataire, concédé en licence large (non exclusive, perpétuelle, irrévocable, incluant le droit de maintenir et modifier par vous-même ou par un tiers) ; et les composants open source, régis par leurs licences propres.
Ce montage à trois couches est sain à condition d'être explicite : exigez la liste de ce qui relève du socle et de ce qui relève du spécifique, et vérifiez que la licence sur le socle vous permet bien de faire vivre l'application sans le prestataire — c'est le cœur de la réversibilité (Réversibilité d'un projet informatique externalisé). Le choix du modèle contractuel interagit avec ce montage : au forfait, la cession se cale naturellement sur la recette des livrables ; en régie, prévoyez explicitement que les droits naissent au profit du client au fur et à mesure (Régie ou forfait : quel contrat choisir pour votre projet de…). Enfin, si votre projet intègre des développements d'agents IA ou des prompts et configurations spécifiques (notre service de création d'agents IA), traitez-les dans l'assiette de la cession au même titre que le code : ce sont des actifs, souvent les plus différenciants.
- Trois couches : spécifique cédé en pleine propriété, socle du prestataire sous licence large, open source sous ses licences propres.
- La licence sur le socle doit permettre maintenance et modification sans le prestataire — sinon la cession du spécifique ne sert à rien.
- Exigez la liste écrite de ce qui relève du socle et du spécifique, dès le devis.
- En régie, stipulez la naissance des droits au profit du client au fil de l'eau.
- Prompts, configurations et modèles d'agents IA font partie de l'assiette : ce sont des actifs cessibles comme le code.
Open source : le passager clandestin de votre propriété intellectuelle
Aucun développement moderne ne part de zéro : votre application intégrera des dizaines de bibliothèques open source, et c'est une bonne chose — à condition de maîtriser leurs licences. Les licences dites permissives (MIT, Apache 2.0, BSD) autorisent l'usage commercial et la modification avec des obligations légères, essentiellement de mention ; elles sont compatibles avec un logiciel propriétaire. Les licences dites copyleft, dont la famille GPL, imposent en revanche que les œuvres dérivées soient distribuées sous la même licence : un composant GPL intégré au cœur d'un logiciel que vous distribuez peut contaminer l'ensemble et vous obliger à en publier les sources. La portée exacte dépend de la licence (la LGPL ou l'AGPL ont des logiques différentes) et du mode d'intégration : le sujet mérite une vraie analyse, pas un slogan.
Contractuellement, la parade est simple : exigez du prestataire un inventaire des composants tiers utilisés avec leurs licences (l'industrie appelle cela une SBOM, software bill of materials), une clause interdisant l'intégration de composants à licence incompatible avec votre usage prévu sans votre accord écrit, et une garantie d'éviction par laquelle le prestataire vous garantit contre les revendications de tiers sur le code livré. Pour un logiciel destiné à un usage purement interne, les contraintes copyleft sont souvent moins mordantes que pour un logiciel distribué ou vendu en SaaS — raison de plus pour que votre contrat précise la destination de l'application, comme l'exige de toute façon le formalisme de cession vu plus haut.
- Licences permissives (MIT, Apache 2.0, BSD) : compatibles avec un logiciel propriétaire, obligations légères de mention.
- Licences copyleft (famille GPL) : risque de contamination — l'œuvre dérivée distribuée doit être publiée sous la même licence.
- Exigez l'inventaire des composants tiers et de leurs licences (SBOM) à chaque livraison.
- Clause d'interdiction des licences incompatibles avec votre usage, sauf accord écrit.
- Garantie d'éviction : le prestataire répond des revendications de tiers sur le code qu'il livre.
Au-delà du contrat : la possession effective du code et des accès
Une cession parfaite sur le papier ne vaut rien si, le jour où la relation se tend, le code est introuvable, obsolète ou inutilisable. La propriété juridique doit se doubler d'une possession effective, organisée dès le premier jour : le code vit dans un dépôt qui vous appartient (compte et organisation à votre nom), le prestataire y travaille par accès que vous contrôlez, et les livrables incluent tout ce qui est nécessaire pour reconstruire et déployer l'application — scripts de construction, configuration d'infrastructure, documentation d'installation. Ce principe simple élimine la moitié des contentieux : on ne retient pas en otage un code que le client a toujours eu.
Complétez le dispositif selon les enjeux : dépôt des sources auprès d'un tiers de confiance — en France, l'Agence pour la protection des programmes (APP) propose ce type de services d'entiercement — utile surtout quand vous dépendez d'un progiciel dont l'éditeur ne cède pas les sources ; procès-verbaux de livraison qui listent précisément ce qui est remis ; et vérification périodique que ce qui est déposé se reconstruit réellement. Ces exigences sont un excellent révélateur en phase de sélection du prestataire : celui qui travaille naturellement dans vos dépôts et documente ses livrables n'a rien à retenir, et cela se sent dès l'avant-vente (Comment choisir un prestataire de développement informatique au Maroc). C'est le standard que nous appliquons chez CRYSTAL IT pour les développements clients — dépôts du client, cession écrite, inventaire des composants — parce qu'un client propriétaire de son code est un client libre de rester pour de bonnes raisons.
- La propriété juridique sans possession effective ne protège pas : code dans vos dépôts, à votre nom, dès le jour un.
- Livrables complets : sources, scripts de construction, configuration, documentation d'installation et d'exploitation.
- L'entiercement (par exemple auprès de l'APP en France) sécurise les cas où les sources ne sont pas cédées.
- Procès-verbaux de livraison détaillés et tests périodiques de reconstruction.
- Un prestataire qui organise votre autonomie dès l'avant-vente signale sa solidité — l'inverse aussi.
En matière de commande logicielle, le droit français ne protège que les clients qui l'écrivent : sans cession conforme — droits énumérés, étendue, destination, lieu et durée précisés, comme l'exige l'article L131-3 du CPI —, le code que vous payez reste la propriété de votre prestataire. Les réflexes qui changent tout tiennent en une page de contrat et une organisation simple : cession écrite au fil des livrables, montage à trois couches assumé (spécifique cédé, socle licencié largement, open source inventorié), garantie d'éviction, et possession effective du code dans vos propres dépôts dès le premier jour. Ces exigences ne sont pas agressives : elles sont le standard des relations saines, et les prestataires solides les acceptent d'autant plus volontiers qu'elles découragent leurs concurrents fragiles. CRYSTAL IT, éditeur de logiciels à Rabat depuis plus de 20 ans, contractualise ainsi ses développements pour clients français (nos services d'offshoring informatique) : si vous préparez un projet externalisé — ERP (notre service de développement ERP), application mobile (notre service de développement d'applications mobiles) ou site web (notre service de création de sites web) —, parlons-en, contrat sur la table. Cet article présente le cadre général et ne remplace pas le conseil d'un avocat sur votre situation particulière.
Un projet ou une question ? Parlons-en avec un expert CRYSTAL IT.
Demander une démo
