Choisir un contrat pour protéger son code source en SASU informatique

Qui possède le code que vous tapez toute la journée, vous ou la SASU dont vous êtes l'unique actionnaire ? Posez la question à un développeur fraîchement passé en SASU informatique et regardez sa tête. La plupart n'y ont jamais pensé. Moi non plus, avant qu'une histoire de contrat de prestation mal ficelé ne me pousse à creuser la protection du code source d'un peu plus près que prévu.

Après six ans à coder en indépendant, j'avais fini par choisir la SASU plutôt que l'EURL, pas sans hésiter. Un pote freelance m'avait vanté l'EURL avec des arguments qui, en y repensant, ne collaient pas du tout à ma situation : lui gérait un petit cabinet à deux, moi je codais seul depuis chez moi. J'ai failli suivre son conseil bêtement, juste parce qu'il avait l'air sûr de lui. Mauvaise idée : la SASU correspondait bien mieux à ce que je voulais faire, notamment sur le régime social du président, là où sa situation à lui répondait à des contraintes complètement différentes.

Une fois le choix fait, je me suis senti comme un seul bloc : moi, ma boîte, pareil. Faux. La loi voit midi à sa porte et compte deux personnes distinctes : Théo le développeur, et la SASU, cette entité qui a son propre numéro et sa propre existence sur le papier. La première facture éditée à l'en-tête de la société, je l'ai gardée une semaine sur le coin du bureau avant de la ranger, presque intimidé qu'un bout de papier porte désormais un autre nom que le mien.

Qui possède le code que vous tapez toute la journée ?

La réponse tient en une phrase que personne ne m'a donnée clairement au début : par défaut, c'est vous. Pas votre société. Le principe général veut que celui qui écrit une œuvre — un texte, un logiciel, peu importe — en reste propriétaire tant qu'il n'a rien cédé par écrit. Votre SASU vous paie, d'accord, mais payer un salaire ne transfère aucun droit sur ce que vous produisez. Concrètement, si vous voulez un jour vendre votre activité ou faire entrer un associé, et que rien ne prouve noir sur blanc que la société détient les droits sur son propre logiciel, vous ne vendez qu'une coquille. Ça m'a semblé complètement absurde la première fois : signer un papier pour m'autoriser moi-même à utiliser mon propre code, au nom de ma propre boîte. Mais c'est la règle, et personne ne la contourne.

Signer un contrat avec soi-même, à quoi bon

Concrètement, ça passe par une convention de cession de droits d'auteur entre vous, la personne physique, et votre SASU. Un texte qui dit, en substance : je cède à ma société le droit d'exploiter tel logiciel, dans telles conditions. Rien de sorcier dans l'idée, mais impossible à bâcler sur un coin de nappe — un peu comme visser les pieds d'une étagère avant de poser les livres dessus : sautez l'étape, et tout s'effondre au premier coup de vent. La première fois que j'ai signé l'annexe listant mes cessions, la feuille sortait tout juste de l'imprimante laser, encore tiède, l'encre à peine sèche.

Entre la paperasse de départ et les erreurs de débutant lors de l'immatriculation de ma SASU, ce papier-là est passé au second plan un moment — j'avais déjà bien assez à gérer. Je l'ai fini par intégrer à la gestion courante de la SASU, chaque année, un peu dans le même esprit que pourquoi j'utilise un pack juridique pour les procès-verbaux de ma SASU : garder une trace propre de chaque décision qui compte, plutôt que de tout reconstituer de mémoire le jour où ça coince.

Le contrat de prestation : séparer ce qui revient au client de ce qui reste à vous

Une fois que le code appartient bien à la société, le deuxième front s'ouvre : le contrat de prestation avec les clients. Beaucoup glissent une clause de transfert total et définitif de propriété dès le premier virement reçu. Logique si vous développez un outil sur mesure rien que pour eux. Nettement moins logique si vous réutilisez vos propres bibliothèques ou des bouts de framework maison que vous peaufinez de mission en mission — là, la clause vous dépouille sans le dire clairement.

Nathan, un copain de lycée devenu développeur back-end à son compte du côté de Caen, m'a posé la question presque mot pour mot il y a peu : faut-il tout céder au client, ou seulement une partie ? J'ai fini par distinguer deux tas dans mes contrats : le « code spécifique », propre à la mission, et le « code standard » ou savoir-faire, mes outils à moi, ceux qui reviennent d'un projet à l'autre.

Le savoir-faire n'est pas à vendre à chaque mission

Mon contrat type stipule désormais que la SASU garde la propriété de ses outils de base, mais accorde au client une licence d'utilisation, perpétuelle et large, sur ce qui a été développé pour lui. Le client récupère largement de quoi faire tourner ce qu'il a payé ; moi, je garde la matière première pour la mission suivante. C'est la seule façon que j'ai trouvée de ne pas repartir de zéro à chaque nouveau projet.

L'APP, ce dépôt qu'on vous présente comme indispensable

On m'a conseillé plus d'une fois de déposer mes sources à l'APP, l'Agence pour la Protection des Programmes. C'est le réflexe qu'on vous glisse dans toutes les conversations d'avocat. Honnêtement, pour un développeur solo en SASU, je trouve ça souvent disproportionné. Ce qu'un litige exige avant tout, c'est de prouver l'antériorité : qui a écrit quoi, et quand.

Mon avis, tranché celui-là : un simple historique Git, commits signés, poussés sur un dépôt privé, suffit largement dans l'immense majorité des cas. C'est une preuve technique solide, gratuite, et qui colle à votre façon de travailler au quotidien — pas besoin d'un rituel à part. Payer plusieurs centaines d'euros chaque année pour un dépôt officiel, ça se justifie pour un éditeur qui vend des licences à grande échelle, beaucoup moins pour quelqu'un qui itère seul tous les jours. Cet argent-là, je préfère le garder pour comparer les services de comptabilité en ligne pour ma SASU plutôt que pour un dépôt que je n'ouvrirai peut-être jamais.

Alexia, une lectrice qui anime des formations pour d'anciens responsables RH reconvertis, m'a écrit un jour pour demander si le même souci se posait pour ses supports de cours plutôt que pour du code. Réponse : oui, exactement le même mécanisme — remplacez « logiciel » par « diaporama » et la logique ne change pas d'un poil. Ce n'est pas propre aux développeurs, ni propre à la SASU par rapport à la SAS classique : c'est propre à toute structure où un seul cerveau produit tout ce que la société vend. La question ne se posait tout simplement pas quand j'étais en micro-entrepreneur — il n'y avait pas de société à qui céder quoi que ce soit.

Et une fois signé, qu'est-ce qui change ?

Quand j'ai fait le point avec mon comptable, il a tout de suite vu l'intérêt d'avoir ces cessions en place pour valoriser l'actif de la société — lui n'est pas juriste, mais il a saisi l'angle financier immédiatement. Ça m'a mis une chose en évidence : protéger son code n'est pas qu'une question de vol, c'est une question de valeur d'entreprise, tout simplement.

Je ne suis ni avocat ni conseiller en propriété industrielle, et si vous montez un SaaS destiné à lever des fonds, direction les guides de l'INPI ou un vrai professionnel — pas ce texte. Mais pour un freelance qui structure son activité en solo, l'essentiel tient en une chose : sortir du flou entre le créateur et sa boîte. Concrètement, s'il ne fallait signer qu'un seul papier cette semaine, ce serait la cession entre vous et votre SASU — le contrat client peut attendre une relecture, l'APP peut attendre tout court.