Sécuriser la propriété intellectuelle d'une mission

Quand un prestataire produit du code, des designs ou de la documentation, la question de la propriété intellectuelle est centrale. Sans clause explicite, le client peut se retrouver à payer un développement qu'il ne possède pas pleinement. Voici comment cadrer ce sujet sereinement.

Pourquoi la PI ne se transfère pas automatiquement

C'est la confusion la plus répandue : payer une prestation ne suffit pas à devenir propriétaire de ce qui est produit. En droit français, l'auteur d'une œuvre, y compris un programme informatique, conserve ses droits tant qu'ils n'ont pas été cédés par écrit dans les formes requises. Une facture acquittée n'emporte pas cession.

Pour un client, l'enjeu est de pouvoir exploiter, modifier et faire maintenir le livrable sans dépendre du prestataire initial. Pour un prestataire, l'enjeu est de protéger son savoir-faire réutilisable tout en livrant ce qui a été commandé.

Cette mécanique surprend souvent les acheteurs, habitués à l'idée que l'achat emporte la propriété, comme pour un bien matériel. Une œuvre de l'esprit obéit à une logique différente : le droit distingue le support, qui peut changer de mains, et les droits d'exploitation, qui ne se transmettent que par un acte de cession formel. Comprendre cette différence en amont évite la mauvaise surprise du client qui découvre, en fin de projet, qu'il ne peut pas faire évoluer librement ce qu'il a financé.

Distinguer le livrable du savoir-faire

Tout n'a pas vocation à être cédé. Une distinction saine s'impose entre :

• Le livrable spécifique : code, configuration, documentation produits pour le client. Il a vocation à lui revenir.
• Le savoir-faire et les outils génériques : bibliothèques internes, méthodes, composants réutilisables du prestataire. Ils restent généralement sa propriété, concédés sous licence d'usage.

Cette frontière doit être écrite. Une clause qui cède « tout » sans nuance est souvent refusée par les prestataires sérieux, car elle les déposséderait de leurs propres outils. Un découpage clair facilite la signature.

La clause de cession : ce qu'elle doit contenir

Une clause de cession de droits robuste précise au minimum :

• les droits cédés (reproduction, représentation, adaptation, distribution) ;
• l'étendue géographique et la durée ;
• les supports et destinations d'exploitation ;
• le moment du transfert, idéalement au paiement.

Le détail des droits patrimoniaux et leur articulation contractuelle sont abordés dans le glossaire SOW, qui décrit comment rattacher la cession aux livrables d'une mission précise. Pensez à conditionner la cession effective au règlement intégral : c'est un levier de sécurité pour le prestataire et un point d'attention pour le client.

Méfiez-vous des formules trop génériques. Une clause qui se contente de mentionner « tous droits cédés » sans préciser leur étendue ni leur destination peut se révéler fragile, voire inopposable sur certains aspects. À l'inverse, une clause trop étroite peut laisser le client sans le droit dont il a réellement besoin, par exemple celui d'adapter le livrable ou de le confier à un tiers pour la maintenance. La précision protège les deux parties : elle dit exactement ce qui change de main et ce qui reste.

Le piège de l'open source

La plupart des projets intègrent des composants open source. Chaque licence impose ses propres obligations : certaines très permissives, d'autres imposant la publication des modifications. Ignorer ces clauses peut contaminer la propriété du livrable ou créer des obligations inattendues.

Bonnes pratiques :

• tenir un inventaire des dépendances et de leurs licences ;
• vérifier la compatibilité entre licences combinées ;
• documenter ce qui est open source et ce qui est propriétaire dans le livrable.

Côté client, demandez cet inventaire en annexe. Côté prestataire, le fournir spontanément est un gage de sérieux. Cet inventaire a aussi une valeur défensive : en cas de question ultérieure sur l'origine d'un composant, il prouve que la chaîne de licences a été examinée plutôt que subie.

L'enjeu dépasse le juridique pur. Une dépendance open source mal choisie peut imposer des obligations de publication incompatibles avec un produit que le client veut garder propriétaire. Vérifier la compatibilité des licences au moment de la conception, et non en fin de projet, évite de devoir réécrire des pans entiers de code pour purger une dépendance problématique. C'est moins coûteux en amont qu'en correctif.

Le cas des salariés et des sous-traitants

Quand le code est produit par un salarié du prestataire, le régime des logiciels créés dans le cadre des fonctions s'applique généralement au bénéfice de l'employeur, qui peut ensuite céder au client. Mais en présence de sous-traitants ou de freelances, la chaîne de cession doit être complète : chaque maillon doit avoir cédé ses droits pour que le client reçoive un titre solide.

C'est un point de vigilance majeur dans les montages avec sous-traitance en cascade. Vérifiez que les contrats intermédiaires comportent les cessions nécessaires, faute de quoi le titre final est fragile.

Articuler PI et confidentialité

Propriété intellectuelle et confidentialité se renforcent mutuellement. Un accord de confidentialité protège les informations sensibles échangées, tandis que la clause de PI organise la propriété de ce qui est produit. Les deux sont complémentaires : voir le glossaire NDA pour la partie confidentialité.

Quand la mission touche à des données personnelles, le volet protection des données s'ajoute, encadré par le glossaire RGPD. Ces trois dimensions cohabitent dans un contrat bien construit.

FAQ

Le client est-il automatiquement propriétaire du code qu'il a payé ? Non. Sans cession écrite, l'auteur conserve ses droits. La cession doit être explicite.

Un prestataire peut-il réutiliser le code d'une mission ailleurs ? Pas s'il l'a cédé au client. Il peut en revanche réutiliser son savoir-faire et ses composants génériques s'ils ont été exclus de la cession.

Comment gérer l'open source dans un livrable ? Inventoriez les licences, vérifiez leur compatibilité et documentez la frontière entre code propriétaire et open source.

Quels profils sont concernés ? Tous les métiers produisant des actifs intellectuels, du développement à l'architecture. Voir tous les métiers IT.

ForTeam IT à vos côtés

ForTeam IT accompagne consultants IT freelance et entreprises : missions sélectionnées, calibrage du TJM, mise en relation avec des grands comptes. Découvrez aussi nos guides, notre glossaire IT & ESN et notre grille des TJM.

Rejoindre la communauté