Propriété du code : exigez les sources de votre prestataire

C'est une situation qu'on rencontre régulièrement en audit : une PME utilise depuis des années un outil développé « pour elle », veut le faire évoluer ou changer de prestataire, et découvre qu'elle ne possède ni le code, ni la base de données, ni même les comptes d'hébergement. L'outil qu'elle a financé est en réalité une location. Le prestataire le sait ; c'est souvent son modèle.

Voici ce qu'il faut savoir avant de signer, et comment vérifier si vous êtes déjà captif.

Payer un développement ne vous en rend pas propriétaire

Contre-intuitif mais vrai en droit français : sans clause de cession explicite, les droits sur un logiciel restent à son auteur, même si vous avez payé son développement intégralement. La facture ne vaut pas cession. Si votre contrat ne contient pas une clause de cession des droits patrimoniaux, le code appartient au prestataire.

C'est le premier point à vérifier sur vos contrats existants, et le premier à exiger sur les prochains.

La propriété réelle, c'est quatre choses

Une clause de cession ne suffit pas si, en pratique, vous ne pouvez rien en faire. La propriété qui compte est opérationnelle :

1. Les sources, chez vous. Un dépôt Git au nom de l'entreprise, où le code est versionné en continu. Pas une archive promise « en cas de besoin ».
2. Les comptes à votre nom. Hébergement, nom de domaine, services tiers, base de données : si tout est au nom du prestataire, votre outil peut s'éteindre avec votre relation commerciale.
3. La documentation. Suffisante pour qu'une autre équipe compétente reprenne le projet sans archéologie. C'est le test décisif : un nouveau prestataire pourrait-il démarrer demain ?
4. Vos données, exportables. Dans un format ouvert et documenté. Les données sont à vous dans tous les cas ; encore faut-il pouvoir les récupérer autrement que par captures d'écran.

Les signaux d'alerte

Certaines formules dans un devis ou une conversation doivent vous faire poser des questions :

• « Le code s'appuie sur notre framework propriétaire. » Traduction possible : même avec les sources, personne d'autre ne pourra maintenir l'outil.
• « L'hébergement est compris dans notre forfait. » Très bien, si les comptes sont à votre nom. Sinon, c'est le point de contrôle parfait pour vous retenir.
• « On vous donnera le code si vous partez. » La propriété ne se négocie pas au moment de la rupture, quand le rapport de force est au pire. Elle se constate en continu.
• Une licence d'utilisation là où vous pensiez acheter un développement. Lisez le contrat : « concède un droit d'usage » et « cède les droits » sont deux mondes.

Aucune de ces situations n'est forcément malhonnête. Mais chacune mérite d'être comprise et arbitrée en connaissance de cause, pas découverte trois ans plus tard.

Si vous êtes déjà captif

Pas de panique, mais pas d'attentisme non plus. Dans l'ordre : relisez le contrat pour savoir ce que vous possédez réellement ; demandez calmement la mise à niveau (dépôt à votre nom, documentation, export des données) tant que la relation est bonne ; et intégrez le coût de sortie dans tout arbitrage à venir sur cet outil. Un avis extérieur indépendant aide à objectiver la situation sans la dramatiser.

Notre position

Chez UBNI, la propriété client est une condition d'entrée, pas une option : sources versionnées sur votre dépôt, comptes à votre nom, documentation livrée, formats ouverts. Si on disparaît demain, tout continue de fonctionner. On ne dit pas ça par vertu : un client qui reste parce qu'il est satisfait vaut mieux qu'un client qui reste parce qu'il est enfermé. Exigez la même chose de n'importe quel prestataire, nous compris.