Projet SaaS : comment choisir une structure juridique adaptée à la croissance et aux actifs immatériels ?

Lancer un SaaS ne revient pas seulement à choisir une forme sociale “souple” ou “simple à gérer”. Le véritable enjeu est d’adopter une structure capable d’accueillir la croissance tout en sécurisant ce qui fait la valeur réelle du projet : le code source, la documentation technique, la marque, le nom de domaine, la base de données, les contrats et, souvent, l’équipe fondatrice elle-même. En pratique, beaucoup de jeunes sociétés numériques ne rencontrent pas leurs premières difficultés sur le chiffre d’affaires, mais sur la propriété des actifs immatériels et sur l’organisation des pouvoirs.

Le droit français n’impose évidemment pas une structure unique pour les projets de logiciel en mode service. Il offre au contraire plusieurs cadres possibles. Encore faut-il choisir celui qui correspond à la réalité du projet. Un SaaS amorcé seul, destiné à être exploité sans levée de fonds, n’appelle pas forcément les mêmes arbitrages qu’un produit conçu dès l’origine pour accueillir plusieurs cofondateurs, ouvrir son capital ou préparer une croissance rapide. Le choix de la structure n’est donc pas un simple préalable administratif : il conditionne la manière dont les droits seront détenus, les décisions prises et les investisseurs rassurés.

⸻

Le point de départ : identifier où se trouvent réellement les actifs du SaaS

En droit, la société est un contrat par lequel deux ou plusieurs personnes conviennent d’affecter à une entreprise commune des biens ou leur industrie en vue de partager le bénéfice ou de profiter de l’économie qui pourra en résulter.¹ Cette règle, qui peut sembler générale, a une portée très concrète pour un projet SaaS. Avant même de parler de capital, de président ou de gérance, il faut déterminer ce qui est effectivement apporté au projet et par qui.

Dans beaucoup de cas, le produit n’est pas né dans la société elle-même. Le code a parfois été commencé avant l’immatriculation par un fondateur technique. Le nom du produit a pu être réservé à titre personnel. Le site internet peut avoir été développé par un freelance. La charte graphique et la documentation peuvent avoir été créées par une agence. La société d’exploitation arrive ensuite, comme un véhicule qui commercialise le service, sans toujours détenir formellement tous les éléments qui le composent.

C’est précisément là qu’un premier tri juridique s’impose. Qui détient le code ? Qui est titulaire de la marque ? Qui possède les droits sur la documentation, les interfaces, les textes du site ou les supports commerciaux ? Tant que cette cartographie n’est pas claire, le choix de la structure reste incomplet. La bonne question n’est donc pas seulement : “SAS ou SARL ?” La bonne question est plutôt : “Quelle structure permettra de loger proprement les actifs immatériels et d’organiser leur exploitation sans fragilité ?”

Sur ce point, l’article consacré à la recherche d’antériorités de marque permet de prolonger l’analyse.

⸻

Le code source n’appartient pas automatiquement à la société qui exploite le SaaS

C’est l’une des erreurs les plus fréquentes dans les projets numériques. Une société facture des abonnements, édite les CGV, exploite la plateforme et signe les contrats clients, mais elle ne détient pas correctement les droits sur le logiciel qu’elle commercialise.

En matière de droit d’auteur, le principe est que l’auteur d’une œuvre de l’esprit jouit sur cette œuvre, du seul fait de sa création, d’un droit de propriété incorporelle exclusif et opposable à tous.² Le logiciel est protégé par le droit d’auteur. Pour les logiciels et leur documentation créés par un ou plusieurs salariés dans l’exercice de leurs fonctions ou d’après les instructions de leur employeur, les droits patrimoniaux sont en principe dévolus à l’employeur.³ En revanche, ce mécanisme automatique n’a pas la même portée pour un prestataire indépendant, un cofondateur non salarié ou une agence. Dans ces hypothèses, une cession de droits correctement rédigée reste nécessaire.

En pratique, cela change tout. Un développeur freelance qui réalise un module essentiel du produit n’abandonne pas ses droits parce qu’il a été payé. De la même manière, un cofondateur qui a codé le MVP avant la création de la société ne transfère pas spontanément ses droits à la future structure si rien n’a été régularisé. Or, lors d’une levée de fonds, d’un audit contractuel ou d’une cession, cette faille réapparaît immédiatement. Un investisseur ne s’intéresse pas seulement au produit fonctionnel ; il veut savoir si la société cible détient bien les droits lui permettant de l’exploiter et de le faire évoluer.

L’acte de cession doit d’ailleurs être précis. Le Code de la propriété intellectuelle exige que chacun des droits cédés fasse l’objet d’une mention distincte et que le domaine d’exploitation soit délimité quant à son étendue, sa destination, son lieu et sa durée.⁴ En d’autres termes, une clause de cession vague ou purement décorative est une très mauvaise idée pour un projet SaaS.

⸻

La marque et le nom de domaine doivent suivre une logique de propriété cohérente

Le même raisonnement vaut pour le signe distinctif du produit. En droit français, la marque est un signe servant à distinguer les produits ou services d’une personne physique ou morale de ceux d’autres personnes.⁵ Sa propriété s’acquiert par l’enregistrement.⁶ Là encore, le risque est très concret : un fondateur dépose la marque en son nom personnel pendant la phase de lancement, puis la société exploite le SaaS sous ce signe sans régularisation.

Tant que les relations sont excellentes, cette situation passe souvent inaperçue. Mais elle devient délicate si le fondateur quitte la société, si le capital s’ouvre, ou si une opération de cession intervient. La structure choisie pour exploiter le SaaS doit donc être pensée avec la logique de détention de la marque. Selon les cas, il pourra être pertinent que la société soit directement déposante, ou qu’un transfert, un apport ou une licence soit mis en place. L’important est d’éviter une dissociation mal maîtrisée entre l’activité commerciale et le portefeuille immatériel.

Un exemple courant illustre bien ce point. Deux associés lancent un outil B2B. L’un développe la solution, l’autre travaille le positionnement commercial et dépose le nom du produit à titre personnel, pensant “gagner du temps”. Un an plus tard, ils font entrer un investisseur. Le produit est exploité par la société, mais la marque est extérieure à celle-ci. La situation n’est pas insoluble, mais elle complique inutilement l’opération et alimente les discussions sur la valeur réelle apportée par chacun.

Ici encore, l’article consacré à la recherche d’antériorités de marque éclaire la logique de détention du signe.

⸻

Le bon choix de structure dépend surtout de la trajectoire de croissance

C’est à ce stade seulement que la question de la forme sociale devient vraiment utile. Un projet SaaS très simple, exploité seul, avec peu de besoins de financement externe et une volonté de maîtrise personnelle forte, peut techniquement fonctionner sous plusieurs formes. Mais dès que le projet a vocation à associer plusieurs personnes, à accueillir des investisseurs, à prévoir des mécanismes d’intéressement ou à adapter sa gouvernance au fil de la croissance, la structure doit être pensée comme un outil d’évolution.

La SAS offre, sur ce point, une souplesse particulièrement appréciée. Le Code de commerce prévoit qu’une société par actions simplifiée peut être instituée par une ou plusieurs personnes.⁷ Surtout, les statuts peuvent être aménagés de manière très fine. Ils peuvent par exemple prévoir l’inaliénabilité temporaire des actions pendant une durée n’excédant pas dix ans,⁸ ou encore organiser des mécanismes de sortie forcée dans certaines conditions.⁹ Pour un SaaS, ces outils ne sont pas accessoires. Ils permettent d’encadrer le départ d’un cofondateur, de limiter une revente prématurée de titres, ou de sécuriser l’arrivée d’un investisseur sans déstabiliser l’ensemble de l’équipe.

La SARL obéit à une logique différente. Elle peut parfaitement convenir à une activité numérique, mais elle est souvent plus adaptée à des projets où le cercle des associés a vocation à rester resserré. En particulier, les parts sociales ne peuvent être cédées à des tiers étrangers à la société qu’avec le consentement de la majorité des associés représentant au moins la moitié des parts sociales, sauf majorité plus forte prévue par les statuts.¹⁰ Cette logique de contrôle peut être utile dans certains projets, mais elle est parfois moins fluide lorsque le SaaS est conçu pour accueillir plusieurs tours de table ou des mécanismes de gouvernance plus sophistiqués.

L’article déjà publié sur le choix entre SAS et SARL complète utilement ce point.

⸻

Pour un SaaS, la gouvernance compte autant que la structure

Le choix d’une forme sociale ne peut pas être isolé des questions de gouvernance. Dans un SaaS, les désaccords entre fondateurs ne portent pas seulement sur la répartition du capital. Ils concernent aussi la feuille de route produit, le prix des abonnements, la politique de recrutement, le calendrier de levée, le budget marketing ou la possibilité de revendre rapidement l’entreprise.

La structure la plus adaptée est donc celle qui permet de distinguer clairement ce qui relève du pouvoir de gestion quotidienne et ce qui mérite une décision collective plus encadrée. En pratique, la SAS est souvent choisie pour cette capacité à organiser la gouvernance avec finesse, à travers les statuts et, si besoin, un pacte d’associés. Un pacte bien rédigé peut prévoir des clauses de présence, de vesting, de confidentialité, de non-concurrence, de sortie conjointe, ou encore des mécanismes de bad leaver et de good leaver. La structure seule ne suffit pas ; elle doit être complétée par une architecture contractuelle cohérente.

Prenons un exemple réaliste. Trois fondateurs lancent un SaaS métier : un développeur, un commercial et un profil produit. Le développeur apporte la première version technique, le commercial signe les premiers clients, et le troisième construit l’expérience utilisateur. Si rien n’est prévu sur la détention des droits, la répartition du pouvoir et les conditions d’un départ, le premier conflit sérieux peut paralyser l’ensemble. La question n’est pas seulement de savoir qui possède 30 % ou 40 % du capital. Il faut aussi savoir qui décide, qui peut bloquer, qui peut sortir, et à quelles conditions.

L’article sur le changement de gérant ou de président complète utilement cette lecture.

⸻

Les apports immatériels doivent être pensés très tôt

Dans un projet SaaS, l’apport ne prend pas toujours la forme d’une somme d’argent. L’un des fondateurs peut apporter un code déjà développé, un autre une marque, un autre encore son industrie, c’est-à-dire son travail, ses compétences ou son implication personnelle dans le projet. Le Code civil rappelle que chaque associé est débiteur envers la société de tout ce qu’il a promis d’apporter en nature, en numéraire ou en industrie, et que les apports en industrie ne concourent pas à la formation du capital social même s’ils donnent droit au partage des bénéfices et de l’actif net.¹¹

Ce point est décisif pour les projets de logiciel. Beaucoup de fondateurs pensent “faire simple” en laissant chacun contribuer de manière informelle, puis en répartissant les titres de manière approximative. Pourtant, si un actif central — par exemple le code du MVP, une bibliothèque propriétaire, une documentation technique très structurée ou une marque déjà exploitée — n’est ni apporté ni cédé clairement à la société, celle-ci peut se retrouver dans une situation de dépendance à l’égard d’une personne physique. C’est supportable au démarrage, mais beaucoup moins lorsque le projet prend de la valeur.

Un cas très fréquent mérite d’être signalé. Un développeur crée seul une première version du logiciel avant l’immatriculation. La société est ensuite créée avec un associé commercial. Le produit est exploité par la société, mais aucune cession ni aucun apport du code n’est régularisé. Quelques mois plus tard, les fondateurs se séparent. Le développeur soutient que la société n’a jamais reçu les droits sur le logiciel initial. Le conflit devient alors beaucoup plus difficile à résoudre qu’il ne l’aurait été si la chaîne de propriété avait été sécurisée dès l’origine.

L’article du site sur l’entrepreneur qui crée une société peut également être utile au démarrage.

⸻

L’entrée d’investisseurs révèle immédiatement les faiblesses de structuration

Tant qu’un SaaS est exploité à petite échelle, certaines imprécisions peuvent rester invisibles. Elles réapparaissent presque systématiquement lorsqu’un investisseur, un partenaire stratégique ou un acquéreur potentiel examine le dossier. À ce stade, les questions posées sont très concrètes : la société détient-elle bien les droits sur le code ? La marque est-elle déposée au bon nom ? Les contrats avec les freelances contiennent-ils des cessions de droits exploitables ? Les fondateurs ont-ils des engagements stables ? Le capital est-il organisé de manière lisible ? Les règles de sortie sont-elles anticipées ?

C’est pourquoi la structure choisie pour un SaaS doit être évaluée non seulement au regard du présent, mais aussi à la lumière de ce futur contrôle. Une société qui fonctionne “entre amis” peut devenir juridiquement peu lisible dès que des tiers doivent entrer au capital ou apprécier la valeur du produit. La souplesse de la SAS la rend souvent plus confortable dans ce type d’évolution, sans pour autant constituer une réponse automatique dans tous les cas. À l’inverse, une SARL bien pensée peut convenir à un projet plus fermé, plus patrimonial ou destiné à rester concentré autour d’un nombre limité d’associés exploitants.

L’article sur la modification du capital social complète cette analyse.

⸻

En pratique, quelle structure est la plus adaptée ?

Il n’existe pas de réponse universelle. Pour un SaaS exploité seul ou à très petite échelle, sans recherche d’investisseurs à court terme, avec une volonté de contrôle étroit et une équipe fondatrice très limitée, plusieurs options peuvent rester envisageables. En revanche, dès que le projet vise une croissance structurée, une ouverture du capital, une gouvernance modulable et une valorisation sérieuse des actifs immatériels, la SAS est souvent plus adaptée en pratique.

Il ne s’agit pas d’un réflexe de mode, mais d’une question d’outillage juridique. La SAS permet plus facilement d’organiser les rapports entre associés, d’encadrer les mouvements de titres, d’émettre des actions adaptées à certains équilibres, et d’anticiper l’arrivée d’investisseurs. La SARL conserve néanmoins sa pertinence pour des projets plus fermés, plus stables, ou pour des fondateurs qui recherchent un cadre moins contractuel et moins évolutif. Le choix doit donc être fait à partir du projet réel : nombre de fondateurs, nature des apports, titularité du code et de la marque, besoin de financement, stratégie de croissance et niveau de sophistication de la gouvernance.

Autrement dit, la bonne structure pour un SaaS n’est pas seulement celle qui permet d’immatriculer rapidement la société. C’est celle qui aligne la détention des actifs, la répartition des pouvoirs et la trajectoire de développement.

⸻

Conclusion

Pour un projet SaaS, le choix de la structure juridique ne devrait jamais être réduit à un comparatif abstrait entre SAS et SARL. Le véritable sujet est la capacité de la société à accueillir et protéger la valeur immatérielle créée par les fondateurs. Tant que le code, la marque, la documentation et les droits d’exploitation ne sont pas logés de manière cohérente, la structure reste incomplètement pensée.

En pratique, un projet SaaS solide repose moins sur une forme sociale “idéale” que sur un ensemble cohérent : une société adaptée à la croissance, une gouvernance lisible, des apports correctement documentés, des cessions de droits bien rédigées et une stratégie claire sur les actifs immatériels. C’est cette cohérence qui rend le projet plus robuste, tant dans ses relations internes qu’à l’égard d’un investisseur, d’un partenaire ou d’un acquéreur potentiel.

⸻

FAQ

Peut-on exploiter un SaaS si le code a été développé avant la création de la société ?

Oui, en pratique, mais la situation doit être régularisée. Si le code a été créé par un fondateur avant l’immatriculation, il ne devient pas automatiquement la propriété de la société. Une cession ou un apport doit être envisagé pour sécuriser la chaîne de titularité.

La société qui facture les abonnements détient-elle automatiquement la marque du produit ?

Non. Si la marque a été déposée au nom d’une personne physique ou d’une autre structure, la société d’exploitation n’en devient pas titulaire du seul fait qu’elle l’utilise. Il faut vérifier la propriété du titre et, si nécessaire, organiser un transfert ou une licence.

Une SARL est-elle exclue pour un projet SaaS ?

Pas du tout. Une SARL peut convenir à un SaaS exploité par un nombre limité d’associés, sans perspective forte d’ouverture du capital. En revanche, si le projet doit accueillir des investisseurs ou organiser une gouvernance évolutive, la SAS est souvent plus maniable.

Pourquoi les investisseurs regardent-ils autant la propriété intellectuelle ?

Parce qu’un SaaS tire souvent l’essentiel de sa valeur de ses actifs immatériels. Si la société ne détient pas clairement le code, la marque ou les droits sur des développements essentiels, la valorisation et la sécurité juridique du projet s’en trouvent immédiatement affectées.

« Cet article fournit une information générale et ne saurait se substituer à un conseil juridique adapté à une situation particulière. »