Contrat avec un développeur : comment s'assurer de la propriété du code ?

Introduction

Lors de tout audit d’acquisition d’une société technologique, la première question posée est celle de la propriété du code. Elle se prépare au moment de la signature du contrat de développement, jamais après.

La règle applicable aux prestataires

Le régime dérogatoire qui attribue automatiquement à l’employeur les droits sur les logiciels créés par ses salariés ne s’étend pas aux prestataires externes.

Le code écrit par une agence, un freelance, un stagiaire non salarié ou un cofondateur non salarié reste sa propriété jusqu’à cession écrite.

Le paiement de la prestation ne transfère rien.

La clause de cession

Elle doit respecter le formalisme applicable : mention distincte de chaque droit cédé et délimitation de l’étendue, de la destination, du lieu et de la durée.

Pour un logiciel, les droits pertinents comprennent la reproduction, la traduction, l’adaptation, l’arrangement et toute autre modification, ainsi que la mise sur le marché.

Le droit d’adapter et de modifier est le plus important en pratique : sans lui, le client ne peut pas faire évoluer le code, ce qui vide la cession de son intérêt.

La remise des sources

Une cession sans remise du code source est théorique.

Le contrat doit prévoir la livraison du code source commenté, de la documentation technique, des scripts de déploiement, des schémas de base de données et de tout élément nécessaire à la reprise par un tiers.

Il est utile de conditionner le paiement du solde à cette remise, et d’organiser un dépôt régulier plutôt qu’une livraison unique en fin de mission.

Les éléments préexistants

Un prestataire réutilise ses propres bibliothèques, composants et modules développés antérieurement.

Il ne peut pas les céder sans se priver de son outil de travail, et le client n’a pas besoin de les posséder.

La solution consiste à distinguer les développements spécifiques, cédés, des éléments préexistants, concédés sous licence perpétuelle, non exclusive et transférable, limitée aux besoins d’exploitation du logiciel livré.

Cette licence doit être transférable : à défaut, la cession de la société cliente se heurterait à un obstacle.

Les éléments concernés doivent être identifiés, faute de quoi la frontière se discute au moment le plus défavorable.

Les composants tiers et l’open source

Tout logiciel intègre des briques externes soumises à des licences propres.

Certaines licences dites à réciprocité forte imposent, sous conditions, de distribuer sous la même licence les œuvres qui en dérivent, ce qui peut se révéler incompatible avec une exploitation propriétaire.

Le contrat doit imposer au prestataire de tenir un inventaire des composants utilisés et de leurs licences, de garantir leur compatibilité avec le modèle d’exploitation envisagé, et de solliciter une validation préalable avant d’intégrer un composant sous licence contraignante.

Cet inventaire est systématiquement demandé lors des audits d’investissement ou d’acquisition.

La garantie d’éviction

Le prestataire doit garantir que les développements livrés ne portent pas atteinte aux droits de tiers.

Cette garantie couvre l’hypothèse d’une revendication d’un ancien employeur du développeur, d’un sous-traitant non cédant, ou d’un titulaire de droits sur un composant intégré.

Elle doit prévoir la prise en charge de la défense et des condamnations éventuelles, dans des limites négociées.

Le cas des cofondateurs

C’est une source de fragilité classique dans les jeunes sociétés.

Un cofondateur technique qui développe avant la création de la société, ou sans contrat de travail, conserve ses droits.

Un acte de cession ou d’apport doit régulariser cette situation, idéalement dès la constitution. Une régularisation tardive, dans un contexte de désaccord entre associés, peut devenir bloquante.

Auditer sa chaîne avant qu’un tiers ne le fasse

Les lacunes se découvrent toujours pendant une levée de fonds ou une cession. Notre expertise en contrats informatiques sécurise ces contrats.

En résumé

• La dévolution automatique ne concerne que les salariés : les prestataires supposent une cession écrite.
• Le droit d’adapter et de modifier est indispensable, sans lui la cession est inutile.
• Exiger la remise du code source, de la documentation et des scripts de déploiement.
• Distinguer développements cédés et éléments préexistants sous licence transférable.
• Imposer un inventaire des composants tiers et vérifier la compatibilité des licences open source.