Logiciel sur mesure : le code vous appartient-il vraiment ?

Un cabinet de quatre personnes à Gap a fait développer un petit outil de suivi de ses dossiers. Trois ans plus tard, le développeur ne répond plus. L’outil tourne, mais personne ne sait où il est hébergé ni comment le modifier. Le cabinet a payé, et pourtant il ne maîtrise rien.

Une question simple aurait évité cela, et on la pose rarement avant de signer.

Payer un développeur, est-ce devenir propriétaire du code ?

Non. Le code, c’est le texte des instructions qui font tourner le logiciel. En droit français, un logiciel est une œuvre protégée par le droit d’auteur, et ce droit appartient à celui qui l’a créé (article L111-1 du Code de la propriété intellectuelle). Un contrat de prestation ne le transfère pas à lui seul.

Sans clause précise, le développeur garde donc ses droits. Vous avez payé pour un résultat, et vous pouvez en général l’utiliser pour l’usage prévu. Mais vous n’avez pas forcément le droit de le modifier, de le faire reprendre par un autre, ou de le revendre avec votre entreprise.

Que doit dire le contrat pour que le code soit vraiment à vous ?

Il doit contenir une cession de droits d’auteur, et la loi est exigeante sur sa forme. L’article L131-3 pose deux conditions. Chaque droit cédé doit faire l’objet d’une mention distincte dans l’acte. Et le domaine d’exploitation doit être délimité : son étendue, sa destination, le lieu et la durée.

En pratique, cherchez ces quatre éléments dans le devis ou le contrat :

À vérifier	Une formule qui ne vaut rien	Une formule qui tient
Ce qui est cédé	« Le client est propriétaire du projet »	Les droits de reproduction, de modification et d’utilisation, cités un par un
Pour quel usage	Rien n’est dit	Tous les usages de votre activité, y compris le faire modifier par un tiers
Où	Rien n’est dit	Tous pays, ou une liste précise
Combien de temps	Rien n’est dit	La durée de protection du droit, ou une durée écrite

Un doute sur la rédaction ? Faites relire la clause par un juriste. C’est une petite dépense au regard d’un outil dont vous dépendez chaque jour.

Le code est à vous : pourquoi cela ne suffit-il pas ?

Parce qu’un code remis sans le reste est inutilisable. Posséder des instructions ne sert à rien si personne ne peut les faire tourner. Quatre choses doivent être remises avec lui :

1. Le code lui-même, dans un dossier que vous pouvez ouvrir, pas seulement sur l’ordinateur du développeur.
2. Les accès : l’hébergement, le nom de domaine, les comptes des services branchés sur l’outil. Ils doivent être à votre nom, pas au sien.
3. Une documentation écrite pour qu’un autre développeur reprenne le travail sans appeler le premier.
4. Vos données, dans un format que d’autres logiciels savent lire.

Vérifiez aussi les morceaux de code qui ne sont pas de lui. Un développeur s’appuie toujours sur des briques écrites par d’autres, chacune avec sa licence, c’est-à-dire ses conditions d’usage. Demandez-lui la liste et les conditions. Aucune ne doit vous interdire d’utiliser l’outil dans votre activité.

Faut-il reprendre le code avec un autre prestataire ?

Souvent non, et c’est la nuance qu’on oublie. Savoir que vous pouvez partir change déjà la relation : le prestataire sait que vous n’êtes pas prisonnier. Mais pour un petit outil qui marche, changer de développeur coûte du temps, car le nouveau doit d’abord tout comprendre.

Le vrai test est ailleurs : un second développeur, qui n’a jamais vu le projet, pourrait-il le reprendre avec la seule documentation ? Faites-le relire pendant le projet, pas trois ans plus tard.

C’est aussi le piège d’un logiciel dont l’éditeur arrête la maintenance : notre Focus sur le logiciel métier abandonné montre ce que coûte une dépendance qu’on n’a pas vue venir.

Que demander avant de signer ?

Cinq questions, par écrit, avant le devis :

1. Les droits sur le code me sont-ils cédés, et par quelle clause ?
2. L’hébergement et les comptes seront-ils à mon nom dès le premier jour ?
3. Que recevrai-je à la livraison : code, documentation, données ?
4. Quelles briques de code venues d’ailleurs sont utilisées, sous quelles licences ?
5. Si vous disparaissez demain, qui peut reprendre le projet ?

Une réponse floue à l’une d’elles est une information. Mieux vaut la recevoir avant la signature que trois ans après.

Chez GHIS, c’est le principe de notre offre de logiciel sur mesure : le code, les données et les accès vous sont remis, documentés pour qu’un autre développeur puisse reprendre. Avant d’en arriver là, vérifiez qu’un outil du marché ne fait pas déjà le travail. Le budget d’un projet se construit poste par poste, et la propriété du code en est un.

Un contrat en cours, ou un devis reçu ailleurs ? Écrivez-nous : nous relisons ces cinq points avec vous lors du diagnostic offert, sans engagement.