La réponse en bref
L'acquéreur a besoin d'une chaîne traçable indiquant qui a créé chaque logiciel important et quels droits la société peut exercer ou transférer. Construisez un registre de provenance couvrant fondateurs, salariés, freelances, agences, code acquis, produits tiers et open source. Reliez chaque composant aux contrats, dépôts, dates, licences et exceptions. La règle suisse sur les logiciels de salariés ne doit pas être étendue aux prestataires ou à toute création.
Cartographier les actifs avant la propriété
Recensez applications, bibliothèques, apps, API, scripts, modèles, documentation, designs, bases de données, domaines, marques et secrets. Reliez chaque actif matériel à son dépôt, créateur ou fournisseur, période et responsable.
L'Institut Fédéral de la Propriété Intellectuelle indique que le code source peut être protégé, tandis que les idées, concepts, algorithmes et instructions ne le sont pas en tant que tels. Le droit d'auteur n'est qu'une couche. Contrats, licences, confidentialité, marques, domaines et contrôle opérationnel exigent leurs propres preuves.
| Composant | Origine | Base des droits | Preuve | Exception |
|---|---|---|---|---|
| Plateforme centrale | Fondateur et salariés | Emploi et cessions | Contrats, commits, versions | Écart éventuel |
| Module portail | Agence | Contrat et licence ou cession | Accord, réception, dépôt | Outils antérieurs |
Tracer séparément fondateurs, salariés et prestataires
Documentez créations antérieures à la constitution, apports des fondateurs, dates d'emploi et fonctions. Reliez chaque contributeur à sa relation, période, livrables, activité dans le dépôt et contrat.
Les indications de l'IPI pour les entreprises décrivent une exception pour les programmes créés par les salariés dans l'exercice de leurs obligations. L'article 17 LDA traite des droits exclusifs d'utilisation de l'employeur dans ce cadre. Il ne faut pas en déduire un contrôle automatique du code de prestataire, du code antérieur ou de toute création. Un conseil suisse doit examiner les faits.
Pour freelances et agences, vérifiez contrat signé, livrables, éléments antérieurs, droits, durée, sous-licence, modification et remise. Le paiement ne remplace pas une clause claire.
Séparer propriété, licence et composants tiers
La société n'a pas à tout posséder. Elle doit savoir ce qu'elle possède, ce qu'elle utilise sous licence et si les conditions conviennent à l'opération et à l'exploitation future. Inventoriez SDK, cloud, données, polices, médias, modèles, API et technologie intégrée.
Consignez fournisseur, produit, version, usage, licence, durée, frais, limites, transfert ou changement de contrôle, résiliation et remplacement. Réconciliez achats, dépôts et production.
- Confirmer la partie contractante.
- Comparer licence et usage réel.
- Identifier les apports clients.
- Signaler les services indispensables.
- Conserver mentions et attributions.
Rendre l'open source visible et gouverné
Créez un inventaire depuis dépôts et builds avec package, version, source, licence, usage, modifications et distribution. Les scans aident mais ne remplacent pas l'examen des éléments ambigus.
Les licences imposent des conditions différentes. Ne présentez pas tout open source comme un problème et ne supposez pas qu'une licence permissive supprime toute obligation. Conservez mentions, revues et exceptions; escaladez les composants modifiés, distribués ou sans provenance fiable.
La réponse solide est: nous savons ce que nous utilisons, pourquoi et comment nous respectons les conditions.
Construire le registre de provenance IP
Consignez composant, auteur ou fournisseur, relation, dates, contrat, droits, territoire et durée si utiles, licence open source, preuve, exception et responsable. Reliez ce registre à l'inventaire technique.
Exemple illustratif: une agence a créé un module il y a cinq ans. Le dépôt et les factures existent, mais le contrat n'accorde qu'un usage limité et ne traite pas la modification du code. Classez le point orange ou rouge en attente d'analyse. Une confirmation, une clarification de licence, un remplacement ou une divulgation peuvent être envisagés selon les faits et l'avis juridique.
- Identifier actifs et dépôts importants.
- Lister personnes et sources tierces.
- Associer contrats et licences signés.
- Comparer documents et production.
- Classer les lacunes par impact.
- Attribuer correction et divulgation.
La couleur est un indicateur interne de priorité, pas un certificat juridique. Conservez les faits et le statut de l’analyse professionnelle derrière chaque classement.
Reconstruire l'histoire du produit et le périmètre social
Les lacunes apparaissent souvent lorsque le produit précède la société actuelle. Placez sur une chronologie constitution, activité des fondateurs, anciennes entités, apports, restructurations et acquisitions. Notez quand dépôts, domaines, comptes cloud et contrats clients ont été transférés. Si une entité payait les développeurs et une autre signait les clients, identifiez l'accord qui les relie.
Pour les produits acquis, conservez contrat d'achat, annexes, cessions, consentements et preuves de réalisation. Comparez la liste acquise aux composants encore utilisés. Pour les apports des fondateurs, distinguez une cession exécutée d'une promesse future. Relevez signatures et dates d'effet. Ne comblez pas une lacune historique par une hypothèse actuelle.
Vérifiez marques et domaines avec le code. Confirmez titulaire, accès administrateur, renouvellement et société inscrite. Relevez les noms commerciaux non enregistrés et territoires d'activité. Des spécialistes qualifiés détermineront les recherches, dépôts ou corrections utiles.
Maintenir les preuves après la revue
Intégrez la provenance à l'embauche et aux achats. Les nouveaux contrats de travail ou mandat utilisent des termes approuvés avant le début. Tout logiciel tiers reçoit un responsable, une fiche licence et une revue sécurité. Les contributions sont rattachées à un compte identifié, revues et conservées dans des dépôts contrôlés par la société.
Définissez un processus d'exception. Les ingénieurs doivent savoir quoi faire lorsqu'un package n'a pas de licence, qu'un client fournit du code, qu'un salarié veut réutiliser un élément antérieur ou qu'une agence propose son framework. Documentez décision, restrictions et suivi. Comparez les scans périodiques à l'inventaire approuvé.
Avant de signer la transaction, actualisez le registre et vérifiez les corrections. Séparez preuves factuelles et conclusions juridiques. Technique, juridique et commercial pourront travailler sur la même liste tout en assumant leur propre analyse.
Préparer une due diligence contrôlée
Indexez contrats, avenants, contributeurs, historique des dépôts et versions, licences, mentions, enregistrements et exceptions. Occultez les données sensibles si nécessaire et ouvrez les accès progressivement. Une data room ne supprime ni confidentialité ni protection des données.
Coordonnez juridique et technique. Les juristes interprètent les droits; les ingénieurs montrent ce qui est livré; finance et achats confirment les fournisseurs. La checklist de due diligence technologique relie ce travail à sécurité et résilience. Le guide de préparation confidentielle explique la divulgation progressive.
Ne promettez pas la perfection. Exposez la situation connue et traitez tôt les lacunes matérielles.
Le dossier est vérifiable lorsque chaque composant matériel livré renvoie à un créateur ou fournisseur, au contrat ou à la licence applicable, à une preuve de dépôt ou de build, au responsable des exceptions et au statut de revue juridique.
Les questions des dirigeants
La société suisse détient-elle automatiquement le logiciel créé par un salarié?
La loi prévoit une règle spécifique pour les programmes créés par les salariés dans l’exercice de leurs obligations contractuelles. Son application dépend des faits et ne couvre pas automatiquement prestataires, code antérieur ou tout autre actif.
Payer un freelance transfère-t-il le droit d'auteur?
Le paiement seul ne prouve pas une cession complète. Examinez contrat, livrables, éléments antérieurs, droits et limites avec un spécialiste.
L'open source pose-t-il problème lors d'une vente?
Pas en soi. L'acquéreur attend un inventaire fiable, les licences, les preuves de conformité et les conditions affectant distribution, modification ou transfert.
Que contient le registre de provenance?
Composant, créateur ou fournisseur, relation, dates, contrat, droits ou licence, preuve, dépendances, exception et responsable. Reliez chaque entrée au contrat, au dépôt ou à une autre preuve.
Cette checklist remplace-t-elle un avis juridique?
Non. Elle organise les preuves. Un conseil suisse doit évaluer propriété, licences, lacunes et questions de transfert.
Sources et lectures complémentaires
Équipe éditoriale Continuum
Recherches et outils pratiques pour orienter les propriétaires. Continuum propose un premier regard indépendant et, sur demande, des mises en relation. Les conseils juridiques, fiscaux et de valorisation propres à une transaction relèvent de spécialistes qualifiés.
Votre prochaine étape