Pourquoi le logiciel peut-il changer le prix d'une cession ?
Le logiciel change le prix d'une cession lorsqu'il porte une partie de la valeur : les clients, les processus, les données. Imaginons un repreneur intéressé par une société de location de matériel dont le parc, les contrats et la facturation passent tous par une application développée il y a six ans par un freelance proche du fondateur. L'application fonctionne. Mais aucun contrat ne mentionne de cession des droits, le code est stocké sur le compte personnel du développeur, et lui seul sait déployer une nouvelle version.
Ce cas n'a rien d'exceptionnel. Pour une société qui vend un logiciel en ligne, l'enjeu est encore plus direct : le code est l'actif principal. Dans les deux situations, découvrir ces points après la signature transforme une acquisition en chantier imprévu, au moment où le repreneur a le moins de marge.
À qui appartient réellement le code ?
L'INPI rappelle que les logiciels, et en particulier leur code source, sont protégés par le droit d'auteur (article L112-2 du Code de la propriété intellectuelle). Le titulaire des droits dépend de la manière dont le logiciel a été créé :
- Par un salarié dans l'exercice de ses fonctions : selon le guide de l'INPI « La propriété intellectuelle et l'entrepreneur », les droits patrimoniaux sur le logiciel sont dévolus à l'employeur, et l'INPI conseille de régler la propriété par contrat écrit.
- Par un prestataire extérieur (freelance, agence) : le même guide recommande, lorsqu'on n'est pas l'auteur du logiciel, de s'assurer de la cession des droits d'auteur. Payer la prestation ne suffit pas forcément.
- Par un fondateur, avant la création de la société : il faut savoir comment les droits ont été transmis à la société, question à poser à l'avocat de l'opération.
L'audit rassemble donc les contrats de travail et de prestation, les conditions générales des prestataires et les factures, et vérifie que le dépôt de code, le nom de domaine, l'hébergement et les comptes des stores sont bien au nom de la société cible. Le sujet est approfondi dans notre guide sur la propriété du code source et la réversibilité.
Licences et dépendances : quel inventaire faire ?
Un logiciel actuel assemble des centaines de composants écrits par d'autres, chacun sous sa licence, et certaines licences imposent des obligations. La Free Software Foundation recommande pour les logiciels deux licences copyleft : la GNU GPL et la GNU AGPL, en version 3 ou ultérieure. Le principe du copyleft veut que celui qui distribue une version modifiée en fournisse le code source aux destinataires dans les mêmes conditions. La GPL ne joue qu'en cas de redistribution ; l'AGPL a été pensée pour le cas d'un logiciel modifié mis à disposition en ligne sans être redistribué.
Concrètement, l'audit dresse la liste des composants et de leurs licences, puis signale ceux qui méritent une analyse juridique au regard du modèle de la cible : application distribuée, logiciel installé chez les clients, service en ligne. Les licences commerciales sont aussi examinées : sont-elles au nom de la société, transférables, limitées en nombre d'utilisateurs ?
La CNIL, dans son guide destiné aux développeurs, recommande d'évaluer l'intérêt de chaque dépendance, de privilégier les projets activement maintenus, de garantir contractuellement la maintenance des solutions commerciales et d'anticiper les versions en fin de support. Une cible qui ignore ses dépendances aura une remise à niveau à financer.
Dette technique, sécurité, données : que coûtera la remise à niveau ?
Le coût de la remise à niveau se déduit de trois examens : la dette technique, mesurée par l'état des versions, des tests et de la documentation, la sécurité et l'exploitation, puis les données. L'audit vérifie :
- les versions des langages, des frameworks et de la base de données, et leur date de fin de support ;
- la présence de tests automatisés sur les parcours critiques ;
- la documentation d'installation, de déploiement et des règles métier ;
- les secrets écrits dans le code, les comptes administrateurs oubliés, les failles connues des dépendances ;
- les sauvegardes : existence, fréquence, dernier test de restauration ;
- l'hébergement : contrat, localisation des données, coût récurrent.
Chaque écart est traduit en travaux de remise à niveau, classés par urgence : une liste que le repreneur peut faire chiffrer par le prestataire de son choix et intégrer dans la valorisation. Notre page sur le prix d'un audit de code détaille ce que couvre ce type de mission.
Les données suivent la même logique : elles n'ont de valeur que si elles sont propres, extractibles et utilisées dans le respect du RGPD. L'audit examine leur qualité (doublons, champs vides, historique cohérent), leur structure (peut-on les sortir dans un format standard ?), le registre des traitements, les contrats avec les sous-traitants qui les hébergent ou les traitent, et le lieu d'hébergement. Une base de prospects d'origine inconnue, ou hébergée hors de l'Union européenne sans encadrement, pèse sur la valeur au lieu de l'augmenter. Notre guide sur le RGPD dans un logiciel métier liste les points de contrôle.
Qui fait tourner le logiciel, et que se passe-t-il s'il part ?
La personne clé est souvent le risque le plus sous-estimé. Si un seul développeur, salarié ou extérieur, connaît le déploiement, les mots de passe et les règles métier codées, son départ après la cession peut immobiliser l'outil. L'audit identifie ces personnes, mesure ce qui est documenté et propose un plan de transmission : documentation, transfert des accès, période d'accompagnement à prévoir dans l'accord de cession. Ce scénario est traité sur notre page consacrée au départ du développeur qui connaissait le logiciel.
Quand la cible dépend d'un logiciel édité par un tiers, la continuité se pose autrement. L'INPI propose par exemple un service d'entiercement, qui conserve les éléments déposés et les transmet à des bénéficiaires sous conditions, notamment en cas de défaillance du déposant.
La liste de contrôle de l'audit technique
La liste de contrôle ci-dessous résume ce que l'audit demande au cédant et les signaux qui doivent alerter le repreneur.
| Domaine | Ce qu'on demande au cédant | Signal d'alerte |
|---|---|---|
| Propriété | Contrats de travail et de prestation, clauses de cession | Code écrit par un tiers sans cession écrite |
| Comptes | Dépôt de code, domaine, hébergement, stores, paiement | Comptes au nom d'une personne physique |
| Licences | Inventaire des composants et des licences commerciales | Composant copyleft dans un produit distribué |
| Code | Accès en lecture au dépôt complet | Version en production introuvable dans le dépôt |
| Dette technique | Versions, tests, documentation | Technologie en fin de support, aucun test |
| Sécurité | Historique des incidents, derniers audits | Secrets dans le code, incident jamais documenté |
| Données | Registre des traitements, contrats des sous-traitants | Base sans origine claire, hébergement non encadré |
| Exploitation | Sauvegardes, supervision, coûts d'hébergement | Restauration jamais testée |
| Personnes | Qui déploie, qui corrige, qui connaît les règles métier | Une seule personne, sans documentation |
Comment YMHB Web mène l'audit, et ce qu'il ne remplace pas
YMHB Web intervient avec un accès en lecture au code, aux environnements et à la documentation, dans le cadre de confidentialité fixé par l'opération. L'audit combine la lecture du code, des contrôles outillés et des entretiens avec les personnes qui font tourner le logiciel. Le rapport classe les risques par gravité, décrit les travaux de remise à niveau et liste les questions à porter dans la négociation. Après la signature, si les deux entreprises doivent partager leurs outils, la suite est décrite dans notre page pour unifier les outils après une fusion.
Cet audit ne remplace ni l'audit juridique ni l'audit financier : il les alimente. Il n'est pas toujours utile non plus. Si la cible n'utilise que des logiciels du marché en abonnement, une vérification des contrats et de leur transférabilité suffit souvent ; un audit technique complet se justifie quand un logiciel spécifique porte l'activité.
Questions fréquentes
Qui est propriétaire d'un logiciel développé par un salarié ?
Selon le guide de l'INPI « La propriété intellectuelle et l'entrepreneur », les droits patrimoniaux sur un logiciel créé par un salarié dans l'exercice de ses fonctions sont dévolus à l'employeur. L'INPI conseille toutefois de régler la propriété par contrat écrit. Lors d'un rachat, l'audit vérifie que les auteurs du code étaient bien salariés de la société cible au moment du développement.
Un logiciel développé par un freelance appartient-il à l'entreprise qui l'a payé ?
Pas automatiquement. L'INPI recommande, quand on n'est pas l'auteur d'un logiciel, de s'assurer de la cession des droits d'auteur. Si le contrat de prestation ne prévoit pas de cession écrite, la société cible peut utiliser le logiciel sans en détenir les droits. Dans un rachat, ce point se règle avant la signature, avec l'avocat du repreneur.
Pourquoi les licences open source comptent-elles dans un rachat ?
Les licences open source comptent parce que certaines imposent des obligations. Les licences copyleft recommandées par la Free Software Foundation, la GPL et l'AGPL, obligent sous conditions à fournir le code source des versions modifiées : la GPL en cas de redistribution, l'AGPL aussi pour un logiciel mis à disposition en ligne. Selon le modèle de la cible, ces obligations peuvent toucher son produit.
L'audit technique remplace-t-il l'audit juridique ?
Non, l'audit technique ne remplace pas l'audit juridique : il l'alimente. L'audit technique établit les faits (qui a écrit le code, quels composants et quelles licences, dans quel état, avec quelles personnes clés), puis l'avocat du repreneur en tire les conséquences contractuelles, notamment dans les garanties négociées avec le cédant. Les deux se mènent en parallèle.
Quand lancer l'audit technique dans une opération de rachat ?
L'audit technique se lance dès que le cédant accepte d'ouvrir les accès en lecture, pendant la phase de vérification qui précède la signature. Sa durée dépend de la taille du code, du nombre d'applications, de la documentation disponible et de la rapidité d'accès. Le lancer tôt permet que ses conclusions pèsent réellement sur le prix et sur les garanties.
À lire aussi
Sources
- INPI, « Cas particulier : les logiciels » (droit d'auteur, article L112-2 du Code de la propriété intellectuelle)
- INPI, guide pratique « La propriété intellectuelle et l'entrepreneur » (2016), logiciel créé par un salarié et cession des droits
- INPI, « Déposer une e-Soleau ou un entiercement » (service d'entiercement de l'INPI)
- Free Software Foundation, Recommended copyleft licenses
- Wikipédia (anglais), GNU General Public License : principe du copyleft et cas de l'AGPL
- CNIL, « Maîtriser vos bibliothèques et vos SDK », guide RGPD de l'équipe de développement (27 janvier 2020)