Qui possède le code de votre application sur mesure ?

L’essentiel : En Belgique, faire développer une application par un prestataire ne vous en rend pas automatiquement propriétaire. Le droit d’auteur protège le logiciel, et les droits appartiennent à celui qui écrit le code. Sans une clause de cession écrite dans votre contrat, vous avez payé pour un développement dont le prestataire reste juridiquement propriétaire. Beaucoup de PME l’ignorent et s’en aperçoivent le jour où elles veulent changer de fournisseur. Voici ce qu’il faut exiger, et pourquoi chez Digitis le client repart propriétaire par défaut. Ceci n’est pas un avis juridique, mais un repère pratique.

« J’ai payé, donc c’est à moi. » Eh bien non.

C’est le réflexe le plus naturel du monde. Vous commandez une application métier, vous réglez la facture, vous pensez logiquement que le résultat vous appartient. Pour un meuble ou une voiture, ce serait vrai. Pour du logiciel, non.

La raison tient à la nature de ce que vous achetez. Un développement n’est pas un objet, c’est une œuvre de l’esprit. Et les œuvres de l’esprit obéissent à une logique juridique particulière : celle du droit d’auteur. Payer pour la création d’une œuvre ne vous transfère pas ses droits. Il faut un acte distinct pour ça, et cet acte doit être écrit.

Ce que dit le droit belge

En Belgique, les programmes d’ordinateur sont protégés par le droit d’auteur depuis 1994. Ils sont assimilés à des œuvres littéraires, et cette protection est aujourd’hui inscrite dans le Code de droit économique.

Le principe de base est simple : les droits appartiennent à la personne physique qui crée l’œuvre, et ils lui restent tant qu’une cession n’a pas été formalisée. Vis-à-vis de l’auteur, cette cession doit être écrite. Autrement dit, sans document signé qui transfère explicitement les droits, l’auteur du code en reste le titulaire, même si quelqu’un d’autre a financé le travail.

Les tribunaux interprètent ces cessions de manière restrictive, en faveur de l’auteur. Une formule vague ne suffit pas. Ce qui n’est pas cédé noir sur blanc reste au développeur.

La différence entre un salarié et un prestataire

Il y a une nuance qui explique pourquoi le sujet passe souvent inaperçu.

Quand un logiciel est écrit par un salarié dans le cadre de son travail, la loi prévoit une présomption de cession des droits à l’employeur. L’entreprise qui emploie le développeur récupère donc les droits sur ce qu’il produit, sauf accord contraire. C’est logique, et c’est ce à quoi la plupart des dirigeants sont habitués sans le savoir.

Le problème surgit quand vous faites appel à un prestataire externe : une agence, un développeur indépendant, une société de services. Là, aucune présomption ne joue en votre faveur. Le prestataire est l’auteur, il garde ses droits, et vous n’obtenez que ce que le contrat vous cède explicitement. Si le contrat est muet sur la question, l’application que vous avez commandée reste juridiquement la propriété de celui qui l’a codée.

Le vrai piège : la licence déguisée en propriété

Dans la pratique, peu de prestataires vous disent frontalement « le code reste à nous ». Le piège est plus discret. On vous livre une application qui fonctionne, vous l’utilisez au quotidien, tout va bien. Vous avez le sentiment d’être propriétaire parce que vous êtes le seul à vous en servir.

Sauf que ce que vous avez, souvent, c’est un droit d’usage. Une licence. Le jour où vous voulez faire évoluer l’outil avec quelqu’un d’autre, récupérer le code source pour l’héberger ailleurs, ou simplement quitter le prestataire, vous découvrez que vous n’en avez pas le droit. Le code ne vous a jamais appartenu. Vous êtes dépendant, non pas par la qualité du service, mais par un point de droit que personne n’a soulevé au départ.

C’est une forme de verrouillage. Elle ne se voit pas tant que tout se passe bien. Elle se révèle au pire moment, celui où vous voulez reprendre votre liberté.

Ce qu’une PME doit exiger dans son contrat

La bonne nouvelle, c’est que tout cela se règle en amont, par écrit. Avant de signer un développement sur mesure, quelques points méritent d’être noirs sur blanc.

Une clause de cession des droits patrimoniaux, explicite, qui transfère la propriété du code au client. Le périmètre de cette cession, le plus large possible, pour couvrir les évolutions futures et pas seulement la première version. La livraison effective du code source, pas seulement de l’application compilée, parce qu’un code qu’on ne peut pas lire ni modifier n’appartient à personne d’utile. Et la possibilité d’héberger ce code où vous voulez, chez vous ou chez un tiers de votre choix.

Si un prestataire refuse de céder la propriété ou de livrer le code source, ce n’est pas forcément de la mauvaise foi. Mais c’est un signal. Cela veut dire que son modèle repose en partie sur votre dépendance, et il vaut mieux le savoir avant de s’engager qu’après.

Et si le contrat est déjà signé ?

Beaucoup de dirigeants lisent ce genre d’article après coup, avec une application déjà en production et un contrat qui ne dit rien sur la propriété. Ce n’est pas une impasse.

Rien n’empêche de régulariser par un avenant : un document signé, postérieur au contrat initial, qui organise la cession des droits et la remise du code source. Un prestataire de bonne foi n’a aucune raison de s’y opposer, surtout si la relation se passe bien. C’est même souvent l’occasion de clarifier des points laissés dans le flou au départ, comme le périmètre des évolutions ou les conditions de reprise par un autre prestataire.

Le bon moment pour poser la question, c’est justement tant que la relation est saine. Attendre un litige ou un départ pour découvrir que le code ne vous appartient pas, c’est se placer en position de faiblesse au pire instant. Un échange courtois aujourd’hui vaut mieux qu’une négociation tendue demain.

Pourquoi je livre la propriété par défaut

Chez Digitis, la question ne se pose pas, parce que la réponse est incluse d’office. Quand nous développons une application métier, le client repart propriétaire du code. Il peut l’héberger chez lui, le confier à un autre prestataire, le faire évoluer sans nous. C’est écrit, ce n’est pas une faveur.

Ce choix vient d’une conviction que j’assume complètement : je refuse de construire une dépendance déguisée à mon existence. Un client doit rester avec moi parce que le service est bon, pas parce qu’il est prisonnier d’un code qu’il ne possède pas. Le jour où quelqu’un veut partir, il doit pouvoir le faire proprement, avec ce qu’il a payé.

C’est exactement ce qu’on a fait pour Aquiris, la filiale belge du groupe Veolia : l’application que nous avons développée pour eux a été déployée sur leur propre serveur, avec le code et la documentation de maintenance remis à leur équipe. Ils ne dépendent pas de Digitis pour continuer à s’en servir. C’est la même logique anti-verrouillage que celle qui guide tout notre rapport à la souveraineté numérique : chaque brique qu’on livre doit pouvoir vivre sans nous.

Une application sur mesure est un investissement. Il serait dommage qu’au bout du compte, elle appartienne à quelqu’un d’autre que celui qui l’a payée.