Dans une vente d’entreprise tech, l’acheteur ne cherche pas seulement un produit, il cherche une chaîne de droits solide. Concrètement, il veut être sûr que la société peut exploiter et céder le logiciel sans se faire contester ensuite, ni se retrouver bloquée par une licence non transférable, un freelance mal cadré ou un compte cloud auquel personne n’a vraiment la maîtrise.

En Suisse, l’enjeu se traite souvent sur deux plans. D’abord, un inventaire IP propre, documenté et prêt à déposer en data room. Ensuite, des déclarations et garanties dans le SPA, avec des remèdes adaptés si un risque se matérialise. L’objectif n’est pas de promettre l’impossible, mais de réduire l’incertitude pour éviter une baisse de prix tardive ou des conditions de closing intrusives.

1. Pourquoi l’IP du logiciel devient le point dur du SPA

Un logiciel est rarement un actif « monolithique ». Même dans une PME, on trouve généralement un empilement de briques. Il y a le code écrit par les employés, puis des modules développés par des prestataires, des bibliothèques open source, des services cloud, des API externes, des bases de données, et parfois des éléments de marque comme le nom du produit ou le logo. En pratique, l’acheteur veut des réponses simples à des questions très concrètes. Qui est titulaire des droits sur le code source. Est-ce que les droits ont été cédés correctement pour les contributions externes. Est-ce qu’il existe des restrictions de licence qui empêchent une revente, un changement de contrôle ou une utilisation commerciale. Est-ce que l’entreprise contrôle réellement les accès et les dépôts.

2. Construire un inventaire IP orienté data room

Pour avancer vite avec un acheteur, l’inventaire doit être organisé comme un dossier d’audit, pas comme un classeur interne. Le bon réflexe est de préparer une liste d’actifs et de preuves, puis de déposer les pièces correspondantes dans la data room avec une nomenclature claire. Voici une structure qui fonctionne bien dans la plupart des transactions en Suisse romande, notamment dans les écosystèmes tech à Genève et à Lausanne. Commencez par un registre des dépôts et droits. Décrivez chaque dépôt de code et ses règles d’accès, par exemple GitHub, GitLab ou un dépôt auto-hébergé. Ajoutez un export des droits d’administration, la liste des mainteneurs, et les politiques internes de gestion des accès. Dans beaucoup de cas, c’est aussi le moment de clarifier qui possède les comptes, la société ou un fondateur. Ensuite, constituez un registre des auteurs et contributeurs. L’objectif est de retracer la chaîne de droits. Pour les employés, rassemblez les contrats de travail et les clauses pertinentes sur les créations, puis les documents internes utiles. Pour les freelances et agences, regroupez les contrats, les bons de commande et surtout les clauses de cession de droits, y compris les annexes techniques. Ajoutez un registre des licences. Il doit couvrir les licences logicielles payantes, les licences de SDK, les composants embarqués, et les contrats d’abonnement SaaS nécessaires au fonctionnement du produit. L’acheteur va chercher les restrictions typiques, comme une interdiction de cession, une clause de changement de contrôle, ou un plafond d’usage. Intégrez aussi un registre des dépendances cloud et des accès. Pour un SaaS, ce point est souvent critique. Identifiez les comptes AWS, Azure, Google Cloud, les services d’emailing, de paiement, de monitoring, ainsi que les coffres de secrets. Documentez qui a les droits d’admin, comment les accès sont récupérés en cas de départ, et si l’authentification multi-facteurs est maîtrisée par l’entreprise. Enfin, si votre valeur repose sur des données, préparez un dossier « données et conformité ». Sans entrer dans des promesses risquées, vous pouvez documenter les politiques internes, les mesures de sécurité et les éléments utiles en matière de protection des données, en restant aligné avec la législation suisse et, si vous êtes concernés, avec le RGPD.

3. Les erreurs qui font perdre du temps et du prix

Certaines erreurs reviennent souvent dans les ventes de PME qui ont grandi vite, avec des sprints produit et des équipes mixtes employés et freelances. Le problème n’est pas que votre logiciel est mauvais, mais que les preuves juridiques ne suivent pas toujours la réalité opérationnelle. La première erreur, c’est le code d’un freelance non cédé. Vous avez payé la facture, le code est dans votre dépôt, et tout le monde pense que c’est « à vous ». Or, sans documentation contractuelle claire sur la cession des droits, l’acheteur peut considérer que le risque est trop élevé. Deuxième cas classique, les licences non transférables ou les contrats SaaS avec des conditions qui n’aiment pas les changements de contrôle. Même si le rachat se fait par acquisition d’actions et que la société reste la même, l’acheteur peut exiger une revue contractuelle et, dans certains cas, des consentements. Troisième piège, l’open source mal gouverné. Ce n’est pas l’open source qui est le problème, c’est l’absence de politique interne, l’absence de scans, ou des dépendances ajoutées sans validation. Selon les licences utilisées et votre modèle de distribution, l’acheteur va vouloir comprendre le risque de devoir publier du code ou de devoir remplacer un composant. Quatrième problème, les accès cloud et secrets détenus par une personne. Un fondateur qui a tout sur son téléphone, une MFA liée à un numéro privé, ou des clés API stockées dans un compte personnel, et vous aurez un point de blocage immédiat en closing. Enfin, il y a le sujet des dépôts et branches fantômes. Certaines fonctionnalités critiques ne sont pas dans le dépôt principal, ou se trouvent dans des forks. Le jour où l’acheteur fait un audit technique, il découvre une architecture plus complexe que prévu, et il demande un ajustement des garanties.

4. Clauses SPA à verrouiller pour le code et les licences

Le SPA n’est pas seulement un document de prix. Il sert à répartir le risque entre vendeur et acheteur. La rédaction exacte dépendra de la structure de transaction, du type de société, et du profil de risque. Voici les sujets qui doivent, dans la plupart des cas, être traités explicitement quand un logiciel est au coeur de la valeur. D’abord, les déclarations sur la titularité. L’idée est de confirmer que la société détient, ou a valablement acquis, les droits nécessaires pour exploiter le logiciel tel qu’il est vendu, et que ces droits ne sont pas grevés par des droits de tiers connus du vendeur. Si certains éléments ne peuvent pas être garantis sans réserve, il vaut mieux les discloser clairement en annexe. Ensuite, les déclarations sur les contributeurs. C’est ici qu’on sécurise les prestations externes. Selon votre historique, l’acheteur peut demander des confirmations spécifiques sur les freelances, les anciens employés clés, ou sur des modules identifiés. Dans certains cas, une mesure pragmatique est de préparer des actes de cession ou des confirmations de droits avant la signature ou avant le closing. Puis viennent les déclarations sur les licences et dépendances. L’acheteur veut éviter une surprise du type « une brique essentielle n’est pas cessible » ou « le coût de licence explose après le closing ». La bonne approche consiste à annexer un tableau de licences, avec les restrictions importantes et l’état des paiements, puis à prévoir une conséquence contractuelle si une information était inexacte. Le sujet des accès et environnements doit aussi être traité. Il s’agit de s’assurer que, au closing, l’acheteur obtient la maîtrise effective des comptes techniques, des dépôts, des registres de conteneurs, des stores, et des outils internes. Souvent, cela se matérialise par une liste d’actions de transfert et de remise d’identifiants, avec un procès-verbal de remise. Enfin, discutez les remèdes. Selon la pratique, on voit des mécanismes comme une retenue, une clause d’indemnisation, ou un engagement de correction. Le choix dépend du risque et de votre pouvoir de négociation. Dans tous les cas, un spécialiste M&A et IP peut vous aider à calibrer une solution proportionnée, plutôt qu’un texte trop large qui fait peur à l’acheteur. Si vous êtes en phase de vente dans le canton de Genève ou dans le canton de Vaud, un accompagnement ciblé fait gagner un temps précieux. Sur JuriUp, vous pouvez décrire votre situation et être orienté vers un avocat spécialisé en M&A et propriété intellectuelle, habitué aux SPA et aux audits IP en contexte tech.