À qui appartient le logiciel que vous avez payé

Quand vous payez un logiciel sur mesure, « il est à vous » sonne comme une seule chose. En pratique, ce sont cinq choses, et un contrat qui n'en nomme qu'une laisse les quatre autres à la bonne volonté. Cet article les énumère, montre comment notre propre accord règle la plus délicate, et vous donne deux phrases à poser devant n'importe quel prestataire.

Ce que recouvre la propriété

La propriété se divise en parties qui peuvent chacune finir dans des mains différentes :

• Le code sourceLa version lisible du logiciel, ce dont un développeur a besoin pour le modifier. : sans lui, personne d'autre que le prestataire d'origine ne peut faire évoluer le produit.
• Vos données : tout ce que le système conserve sur vos clients, patients ou commandes, et la possibilité de les exporter à tout moment dans un format lisible par un autre système.
• Les comptes et les domaines : le nom de domaine, l'hébergement, les comptes des app stores et des services tiers, enregistrés à votre nom et non à celui du prestataire.
• La documentation : comment le faire tourner, le déployer, le sauvegarder et le modifier, écrite pour la personne suivante.
• La plateforme réutilisable du prestataire : bibliothèques, modèles et outillage qui existaient avant vous et servent aussi à d'autres clients.

Chacune de ces parties peut être à vous, à eux, ou à personne. Un contrat qui dit « le client est propriétaire du logiciel » sans les nommer a tranché la première et laissé le reste ouvert. C'est là que naissent la plupart des litiges de propriété : tout le monde était d'accord, et personne n'était d'accord sur quoi.

Le livrable et la plateforme sont deux choses différentes

La plupart des prestataires, nous compris, n'écrivent pas chaque projet à partir d'une page blanche. Une partie de ce que vous recevez a été construite pour vous ; une autre est une plateforme que le prestataire réutilise. Un contrat équitable nomme cette séparation au lieu de la cacher derrière un seul mot.

Notre propre accord la règle ainsi. Vous possédez les livrables propres au projet qui sont identifiés dans le périmètre, une fois payés. Nous gardons ce qui existait avant votre projet et ce que nous réutilisons d'un projet à l'autre : bibliothèques, modèles, outillage de déploiement et méthodes. Là où ces éléments réutilisables sont intégrés à votre livrable, vous recevez une licence non exclusive et perpétuelleNon exclusive : le prestataire peut continuer à utiliser le même matériel pour d'autres. Perpétuelle : la licence n'expire pas à la fin de la collaboration. pour les utiliser comme partie de ce livrable, pour votre usage interne.

Deux choses en découlent. Vous ne pouvez pas extraire notre plateforme de votre produit pour la revendre, et nous ne pouvons pas prendre votre travail propre au projet pour le confier à quelqu'un d'autre. Une chose échappe facilement : avoir le dépôt ou l'hébergement sous votre contrôle n'équivaut pas à posséder ce qu'ils contiennent. Notre accord le dit en termes clairs : la garde de l'hébergement, du déploiement ou des dépôts ne transfère pas la propriété par elle-même. Demandez à tout prestataire où passe sa ligne, et demandez à la voir écrite.

Ce que le transfert doit comprendre

La propriété sur le papier vaut peu si rien n'arrive. Un transfert réellement utilisable comprend :

• Accès et propriété transférés : comptes, domaines, identifiants et facturation passés chez vous, rien qui reste chez le prestataire.
• Le code source, avec les instructions pour le construire et le déployer sur une infrastructure que vous contrôlez.
• Un runbook pour le travail courant : déployer, sauvegarder, surveiller, mettre à jour une dépendance.
• Le journal des décisions : pourquoi le système a cette forme, pour que le développeur suivant le modifie en connaissance de cause.
• Les fins ouvertes, nommées : les raccourcis pris sciemment et ce qui viendrait ensuite.

Le test est simple : un autre développeur pourrait-il reprendre le travail avec le seul transfert, sans appeler le prestataire ? Cela ne marche que si le transfert est décrit et chiffré dans le contrat, au lieu de rester une faveur à négocier plus tard. Nous prévoyons le transfert dès le premier jour, précisément pour cette raison.

Si le prestataire disparaît

Des entreprises s'arrêtent, sont vendues ou abandonnent une gamme de produits. Personne ne peut promettre le contraire, alors posez les questions avant de signer :

• Que deviennent le code et les données si l'entreprise s'arrête, est vendue ou abandonne ce produit ?
• Pouvez-vous accéder au code sans leur coopération ?
• Une autre partie pourrait-elle continuer le travail sans tout reconstruire ?
• Quelle est la sortie prévue : préavis, dernier transfert, coût ?

Nous n'avons pas d'arrangement d'escrow standard à montrer, vous n'en trouverez donc pas dans notre accord. Ce que vous y trouverez, c'est la séparation de propriété ci-dessus, le transfert dans le périmètre et des comptes à votre nom.

Deux phrases pour le contrat

Vous n'avez pas besoin de langage juridique pour être clair. Deux phrases en mots simples font l'essentiel du travail :

1. « Le client est propriétaire du code source, des données, de la documentation et des livrables propres au projet listés dans le périmètre, sous réserve de paiement. Le prestataire conserve ses éléments préexistants et réutilisables et accorde au client une licence perpétuelle et non exclusive pour les utiliser comme partie du livrable. »
2. « Le nom de domaine, l'hébergement et les comptes tiers sont enregistrés au nom du client. À la fin de la collaboration, le prestataire remet le code source, les identifiants, les instructions de déploiement et la documentation dans le délai convenu, au prix indiqué dans le présent accord. »

Ce n'est pas un conseil juridique, et votre propre conseil pourra affiner la formulation. Ce sont les deux endroits où un contrat logiciel reste le plus souvent vague. Nos conditions générales précisent que le conseil relève d'une obligation de moyens et que les arrangements concrets sur le périmètre, le prix, l'acceptation et la propriété intellectuelle figurent dans les documents du projet, et c'est là que ces phrases ont leur place.

Un développement sur mesure n'est pas un achat, c'est une propriété. La propriété n'a de sens que lorsque chaque partie porte un nom. C'est ainsi que nous écrivons nos propres accords, et c'est une façon juste de lire ceux de n'importe qui d'autre.