Due diligence juridique d'une startup SaaS : préparer une levée de fonds ou un rachat

Une levée de fonds ou un rachat se joue deux fois : dans la négociation, et dans la due diligence. C'est au second moment que les valorisations fondent, que les garanties de passif enflent et que des deals meurent. Pour une startup SaaS, les points de rupture sont connus et presque toujours les mêmes : un code dont la titularité est incertaine, une stack open source non maîtrisée, des contrats clients hétérogènes, une conformité RGPD déclarative. La bonne nouvelle : chacun de ces points s'audite et se répare en amont. Voici ce que les avocats de l'investisseur vont regarder, et comment arriver prêt.

Ce que la due diligence cherche vraiment

La due diligence juridique n'est pas une formalité administrative : c'est l'exercice par lequel l'acquéreur ou l'investisseur vérifie que ce qu'il achète existe juridiquement. Pour un SaaS, l'actif principal est immatériel : le code, la marque, les données, les contrats récurrents. Si la startup ne détient pas ses actifs ou si ses revenus reposent sur des contrats fragiles, la valorisation n'a plus d'assise.

Les conséquences d'une due diligence défavorable sont graduées : conditions suspensives de régularisation (le deal attend que vous répariez), réduction de prix, extension des garanties d'actif et de passif avec séquestre renforcé, ou abandon pur et simple. Dans tous les cas, le rapport de force se dégrade : chaque anomalie découverte par l'autre partie coûte plus cher que la même anomalie corrigée avant l'ouverture de la data room.

Titularité du code : le point de rupture numéro un

La première question de tout auditeur est simple : la société détient-elle les droits sur son propre logiciel ? La réponse dépend entièrement de qui a écrit le code.

Le code écrit par les salariés : la dévolution automatique

L'article L113-9 du Code de la propriété intellectuelle prévoit que, sauf stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l'exercice de leurs fonctions ou d'après les instructions de leur employeur sont dévolus à l'employeur. C'est un régime dérogatoire favorable à l'entreprise : pour les salariés, la titularité est automatique, sans contrat de cession.

Deux limites tout de même : la dévolution suppose un lien avec les fonctions ou les instructions de l'employeur (le projet personnel d'un développeur mené hors de ses fonctions n'est pas couvert), et elle ne vaut que pour les logiciels. Les autres créations d'un salarié (design, contenus, éléments graphiques d'interface relevant du droit d'auteur classique) obéissent au régime général et nécessitent une cession expresse.

Le code écrit par des freelances et prestataires : le piège classique

C'est ici que les startups perdent des points en due diligence. La dévolution automatique de l'article L113-9 ne s'applique pas aux indépendants, freelances et sociétés prestataires. Sans cession écrite, le freelance qui a développé votre MVP, votre application mobile ou un module critique reste titulaire des droits patrimoniaux sur son code. Vous payez la prestation, vous ne détenez pas l'actif.

Et une simple mention « tous droits cédés » ne suffit pas : l'article L131-3 du même code impose que la transmission des droits d'auteur fasse l'objet d'une mention distincte pour chaque droit cédé, et que le domaine d'exploitation des droits cédés soit délimité quant à son étendue, sa destination, son lieu et sa durée. Une cession mal rédigée est une cession fragile, que l'auditeur signalera comme telle.

Conseil d'avocat : faites l'inventaire de tous les contributeurs au code depuis l'origine (salariés, stagiaires, freelances, agences, associés avant la constitution de la société) et vérifiez pour chacun le fondement de la titularité. Le code écrit par un fondateur avant l'immatriculation appartient au fondateur, pas à la société : c'est un apport ou une cession à formaliser, et l'oublier crée une faille de titularité au cœur même de l'actif.

Le code écrit par les associés avant la société : l'angle mort classique

L'article L113-9 organise la dévolution automatique des droits à l'employeur mais un associé n'est pas salarié, et un fondateur qui code avant l'immatriculation n'a même pas d'employeur du tout. Le MVP tapé un week-end avant la création de la société appartient à la personne physique qui l'a écrit, pas à la structure. La régularisation passe par un apport en nature (évalué par un commissaire aux apports au-delà des seuils légaux) ou par une cession respectant l'article L131-3 : mention distincte par droit cédé, étendue, destination, lieu et durée précisés. Un procès-verbal évoquant vaguement « l'apport du savoir-faire technique » ne vaut pas mieux qu'une cession freelance bâclée un auditeur le retoquera tout aussi vite.

Autre cas fréquent : l'associé technique parti avant tout formalisme. Sans clause de titularité dans le pacte d'associés, il reste détenteur de sa contribution au code même après cession de ses parts. La société exploite alors un actif dont elle ne possède qu'une partie des droits.

Conseil d'avocat : pour chaque associé ou dirigeant ayant codé, vérifiez la date d'immatriculation par rapport à la date de création du code, l'existence d'un apport ou d'une cession formalisée, et la présence d'une clause de titularité couvrant l'hypothèse d'un départ. Une brique manquante, et c'est la même faille que le freelance non cédé : un actif que vous croyez détenir sans le détenir vraiment.

Open source : la stack que personne n'a jamais auditée

Tout SaaS moderne repose sur des composants open source. L'auditeur ne reprochera jamais leur usage : il vérifiera qu'il est maîtrisé. Les licences permissives (MIT, Apache 2.0, BSD) posent peu de contraintes. Les licences copyleft (GPL, AGPL notamment) peuvent imposer, selon la manière dont le composant est intégré, des obligations de mise à disposition du code source qui sont incompatibles avec un modèle propriétaire. L'AGPL, conçue pour les usages en réseau, est le point de vigilance spécifique du SaaS.

Ce que la due diligence attend : un inventaire des composants et de leurs licences (via les outils d'analyse de composition logicielle), une politique d'intégration documentée, et le traitement des cas sensibles. Une startup qui présente cet inventaire spontanément marque des points ; celle qui le découvre pendant l'audit subit le calendrier. Le sujet est détaillé dans mon article sur les risques juridiques de l'open source.

Contrats clients : la valeur récurrente sous la loupe

La valorisation d'un SaaS repose sur ses revenus récurrents. L'auditeur va donc éprouver la solidité juridique de ce récurrent : CGV ou contrats signés et opposables (preuve de l'acceptation), clauses de durée et de reconduction, facultés de résiliation, plafonds de responsabilité, engagements de niveaux de service réalistes, et clauses de changement de contrôle. Ce dernier point est souvent découvert en due diligence : si vos contrats grands comptes permettent au client de résilier en cas de changement de contrôle, une partie du récurrent est juridiquement conditionnée à l'accord de vos clients, ce que l'acquéreur intégrera dans le prix ou les conditions suspensives.

Un point de structuration paie particulièrement : l'homogénéité. Un socle contractuel unique avec des variantes maîtrisées s'audite en quelques jours ; cinquante contrats négociés sans version de référence s'auditent en semaines, et chaque écart devient une question. La structuration du contrat SaaS en amont est un investissement direct dans la valorisation, d'autant que la conformité des clauses de réversibilité au Data Act fait désormais partie de la revue.

RGPD : la conformité déclarative ne passe pas l'audit

La due diligence RGPD d'un SaaS B2B porte sur des livrables précis : registre des traitements, contrats de sous-traitance conformes à l'article 28 avec les clients (votre DPA) et avec vos propres sous-traitants (hébergeur, outils intégrés), encadrement des transferts hors Union, politique de durées de conservation, procédure de gestion des violations, et le cas échéant analyses d'impact. L'auditeur vérifie la cohérence de la chaîne : ce que vous promettez à vos clients dans votre DPA doit être effectivement répercuté sur vos sous-traitants. Une incohérence dans cette chaîne (un sous-traitant américain non documenté, un DPA client plus protecteur que vos contrats fournisseurs) est un passif transférable, donc un sujet de garantie.

Le reste de l'actif immatériel : marque, noms de domaine, bases de données

Trois vérifications rapides mais fréquemment défaillantes. La marque : déposée, dans les bonnes classes, au nom de la société (pas du fondateur), sur les territoires où le SaaS est commercialisé. Les noms de domaine : enregistrés au nom de la société, avec un accès administratif maîtrisé (un domaine au nom d'un ancien prestataire est un risque opérationnel et juridique). Les bases de données : le régime du producteur de bases de données peut protéger vos données d'usage, à condition de pouvoir justifier d'un investissement substantiel dans leur constitution. Ces sujets relèvent de la propriété intellectuelle classique, et se règlent en quelques semaines quand ils sont pris à temps.

Le passif social et les promesses : les sujets qui fâchent en fin d'audit

Deux zones méritent une revue spécifique avant d'ouvrir la data room. Les BSPCE et promesses d'equity d'abord : attributions conformes aux décisions sociales, plafonds respectés, promesses orales ou par mail à des salariés ou advisors documentées et purgées. Un acquéreur déteste découvrir des droits dilutifs non formalisés. Le statut des équipes ensuite : le recours massif à des freelances de longue durée, intégrés aux équipes, expose à un risque de requalification qui sera valorisé dans la garantie de passif. Là encore, mieux vaut auditer et corriger soi-même que laisser l'autre partie chiffrer le risque.

La data room idéale : ce que vous devez pouvoir produire

Une startup SaaS prête pour une due diligence produit sans délai : la chaîne complète de titularité du code (contrats de travail avec clause PI, cessions freelances conformes à L131-3, apports des fondateurs), l'inventaire open source, le socle contractuel client avec la liste des écarts négociés, le dossier RGPD (registre, DPA, sous-traitants, transferts), les titres de PI (marques, domaines), la documentation corporate (pactes, BSPCE, décisions), et les contrats fournisseurs critiques (hébergement, briques logicielles). Ce niveau de préparation change la dynamique de négociation : vous répondez en jours, vous limitez les garanties demandées, et vous envoyez le signal d'une société gérée.

Douze mois avant l'opération : la vendor due diligence

Le meilleur moment pour passer cet audit est avant d'en avoir besoin. Une revue menée douze à dix-huit mois avant une levée ou une cession laisse le temps de réparer : régulariser les cessions de droits manquantes auprès d'anciens freelances (ce qui se négocie mieux à froid qu'en urgence de closing), homogénéiser les contrats clients au fil des renouvellements, remettre le dossier RGPD à niveau, purger les promesses d'equity. C'est exactement le sens de l'accompagnement des startups et entreprises innovantes : transformer la due diligence d'épreuve subie en formalité préparée.

Si vous préparez une levée de fonds, une cession ou l'entrée d'un partenaire stratégique, vous pouvez échanger sur votre situation directement avec moi : un pré-audit ciblé sur la titularité du code, les contrats et la conformité données identifie en quelques jours les sujets à traiter avant d'ouvrir votre data room, et la protection de votre logiciel en sort renforcée pour la suite.