Audit de code source avant un rachat ou une intégration : ce qu'on vérifie vraiment

Un audit de code source ne se conclut presque jamais par « le code est mauvais ». Il se conclut par « personne ne sait qui détient ce code », et ce constat coûte plus cher qu'une dette technique. Sur une acquisition d'éditeur, la titularité des développements et la conformité des licences open source sont les deux postes qui déclenchent le plus de garanties spécifiques et de séquestres de prix. Voici ce qu'un auditeur ouvre réellement dans un dépôt, et comment préparer sa base de code avant qu'un acquéreur ne vienne la regarder.

Ce qu'un audit de code source cherche vraiment

Un audit de code source juridique ne mesure ni la couverture de tests, ni la complexité cyclomatique, ni la qualité de l'architecture. Ces indicateurs relèvent de la due diligence technique, que mène le directeur technique de l'acquéreur. L'audit juridique répond à trois questions, et à trois seulement.

1. La société vend-elle ce qu'elle détient ? La chaîne de cession des droits est-elle complète, du premier commit au dernier ?
2. L'exploitation du produit expose-t-elle l'acquéreur à l'action d'un tiers ? Un auteur qui n'a rien cédé, une licence open source violée, du code venu d'un ancien employeur.
3. Le produit pourra-t-il être exploité et distribué demain dans les mêmes conditions qu'aujourd'hui ?

La troisième question est celle qu'on oublie, et souvent la plus coûteuse. Un composant sous licence AGPL dans un service accessible uniquement par le réseau ne pose pas le même problème que dans un produit livré chez le client. L'acquéreur qui prévoit de basculer le produit en version installable hérite d'obligations de publication que le vendeur n'a jamais eu à assumer. Un audit se lit donc à la lumière du projet de l'acheteur, pas du seul usage actuel du vendeur.

Le même exercice vaut hors acquisition : intégration technique, marque blanche, reprise d'une base après la défaillance d'un prestataire. Pour la due diligence juridique d'ensemble, qui couvre les contrats clients, le passif social et la conformité, j'ai écrit un guide dédié, la due diligence juridique d'une startup SaaS. Ici, on descend d'un cran, dans le dépôt lui-même.

La chaîne de titularité, le point qui fait échouer les deals

La question n'est pas de savoir si la société « a » un logiciel, mais si chaque ligne de ce logiciel a bien rejoint son patrimoine. Le droit français ne pose qu'une seule dévolution automatique, et elle est étroite.

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

L'article L. 113-9 du code de la propriété intellectuelle prévoit que, sauf dispositions statutaires ou 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, seul habilité à les exercer. Le texte vise aussi les agents publics.

Trois limites. La dévolution ne couvre que les logiciels et leur documentation. Elle ne porte que sur les droits patrimoniaux. Elle suppose une création dans l'exercice des fonctions ou d'après instructions : un salarié recruté sur un poste commercial qui développe un module le week-end n'entre pas mécaniquement dans le champ. Un auditeur sérieux demande donc les contrats de travail et les fiches de poste, pas seulement le registre du personnel.

Le stagiaire et le doctorant relèvent de l'article L. 113-9-1, sous quatre conditions cumulatives : être accueilli par convention dans une structure réalisant de la recherche, créer dans l'exercice de ses missions ou d'après les instructions de cette structure, percevoir une contrepartie, être placé sous l'autorité d'un responsable. Hors de ce cadre, aucune dévolution. Le stagiaire qui a écrit le moteur de calcul en reste titulaire tant qu'un écrit ne cède rien.

Le freelance qui a codé le prototype

Pour un prestataire indépendant, une agence ou une société de services, il n'existe aucune dévolution automatique. Payer une facture ne transfère aucun droit. C'est l'erreur la plus répandue, et la plus chère.

La cour d'appel de Colmar l'a rappelé le 9 avril 2025 (1re chambre, section A, n° 24/01625), à propos d'un logiciel de gestion de contenu développé par une équipe mixte. Elle a reconnu la titularité à la société prestataire, qui avait assuré 76 % de la programmation, dirigé le projet et rédigé la documentation technique, la cliente n'ayant contribué qu'à hauteur de 21 %. Faute d'acte de cession écrit, cette dernière est restée simple utilisatrice.

La conséquence est brutale : si la cible n'est pas titulaire, elle ne peut pas céder. Et l'exploitation qu'elle poursuit peut être qualifiée de contrefaçon. L'article L. 335-3 du code de la propriété intellectuelle érige en délit la violation de l'un des droits de l'auteur d'un logiciel définis à l'article L. 122-6, punie selon l'article L. 335-2 de trois ans d'emprisonnement et de 300 000 euros d'amende. Le volet pénal reste rare en pratique, mais il suffit à justifier une garantie spécifique et un séquestre de prix.

Le contrat de cession, et ce que vaut « cède tous droits »

L'article L. 131-2 du code de la propriété intellectuelle impose que les contrats transmettant des droits d'auteur soient constatés par écrit. L'article L. 131-3 ajoute que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte, et que le domaine d'exploitation soit délimité quant à son étendue, à sa destination, au lieu et à la durée.

Pour du logiciel, les droits à viser sont ceux de l'article L. 122-6 : la reproduction permanente ou provisoire, y compris celle qu'impliquent le chargement, l'exécution et le stockage ; la traduction, l'adaptation ou toute autre modification ; la mise sur le marché, location comprise. Une clause muette sur le droit d'adaptation laisse l'acquéreur sans droit clair de faire évoluer le code qu'il vient d'acheter.

Deuxième piège, l'article L. 131-1 frappe de nullité la cession globale des œuvres futures : un contrat cadre qui cède par avance les droits sur tous les développements à venir, sans les rattacher à un livrable identifié, est fragile. La parade tient en une ligne, rattacher la cession à chaque bon de commande. Troisième piège, céder des droits n'est pas remettre le code : sans clause de remise des sources, de la documentation et des scripts de construction, l'acquéreur détient des droits qu'il ne peut pas exercer.

Point de vigilance : la clause « le prestataire cède au client l'ensemble de ses droits de propriété intellectuelle sur les livrables » ne dit ni quels droits, ni pour quelle destination, ni pour quel territoire, ni pour quelle durée. Face à un acquéreur exigeant, elle ne vaut pas grand-chose. Je préfère une clause qui énumère les droits de l'article L. 122-6, précise « tous supports, tous territoires, pour la durée légale de protection », rattache la cession à un livrable identifié et impose la remise des sources. Trois lignes de plus, et le poste sort des réserves. C'est le cœur de mon travail de protection des logiciels.

Ce qu'on ouvre réellement dans un dépôt Git

Un audit de titularité ne se fait pas sur déclaration. Il se fait sur l'historique, parce que l'historique dit qui a écrit quoi, quand, et depuis quelle adresse. Voici ce que je regarde en premier, et ce que chaque signal veut dire.

La liste des auteurs

Un git shortlog -sne --all sort la liste complète des contributeurs, avec leur adresse électronique et leur nombre de commits, toutes branches confondues. On la confronte à deux listes : le registre du personnel et la liste des prestataires facturés. Tout auteur qui n'apparaît dans aucune des deux est un trou dans la chaîne de titularité.

Les signaux qui appellent une question : un pseudonyme jamais rattaché à une personne identifiée, une adresse portant le domaine d'un ancien employeur d'un fondateur, un fichier .mailmap qui fusionne des identités sans explication. Chacun se règle avec un document, jamais avec une déclaration orale en réunion.

Les dates et le commit initial

Le premier commit est souvent antérieur à l'immatriculation de la société. C'est un angle mort classique : le code écrit par les fondateurs avant la création de la personne morale leur appartient à titre personnel et doit avoir fait l'objet d'un apport en nature ou d'une cession écrite. Ce document coûte quelques centaines d'euros douze mois avant une opération, et devient une condition suspensive de closing quand on le découvre trois semaines avant la signature.

Autre point de contrôle, l'« initial commit » qui ajoute quatre-vingt mille lignes d'un seul coup. Il ne dit rien de l'origine du code : gabarit acheté, projet précédent d'un fondateur, base récupérée sur un dépôt public, code d'un ancien employeur. L'auditeur demande d'où vient cette masse et sous quelle licence elle a été obtenue. « C'est notre premier prototype » n'est pas une réponse.

Ce que le gestionnaire de dépendances ne voit pas

Les outils d'analyse de composition logicielle lisent les fichiers de dépendances. Ils ne voient pas le code tiers copié à la main : un répertoire vendor/ ou third_party/ commité en dur, une bibliothèque minifiée déposée dans les ressources statiques, une fonction copiée sur un site d'entraide entre développeurs, dont le contenu est diffusé sous une licence qui exige l'attribution. Ces morceaux se repèrent autrement : en-têtes de licence orphelins, style de code hétérogène, fichiers entiers sans historique de modification.

Manquent presque toujours, enfin, quatre éléments simples : un fichier de licence à la racine, un fichier d'attributions listant les composants tiers, une politique de contribution, et un garde-fou d'intégration continue qui refuse une dépendance sous licence non autorisée. Leur absence n'est pas une faute, c'est un indicateur : aucune revue de licences n'a eu lieu.

Les licences open source, la lecture qui compte

Trois familles suffisent à cadrer l'essentiel. Les permissives, MIT, BSD ou Apache 2.0, demandent la conservation des mentions de droit d'auteur et de licence, Apache 2.0 ajoutant une concession de brevet. Le copyleft faible, LGPL ou MPL 2.0, impose de redistribuer les modifications du composant lui-même, la MPL raisonnant fichier par fichier. Le copyleft fort, GPL v2 et v3, impose que l'ensemble distribué le soit sous la même licence, code source compris. L'AGPL étend cette obligation à la mise à disposition par le réseau : c'est la licence qui vise les éditeurs SaaS.

La question qui décide n'est donc pas « quelle licence ? » mais « distribuez-vous ? ». Un service accessible uniquement par le réseau ne déclenche en principe pas l'obligation de publication de la GPL, faute de distribution. La même base livrée en version installable, embarquée dans une image de conteneur remise au client ou déployée sur son infrastructure la déclenche.

La sanction n'a rien de théorique en France. Après l'arrêt de la Cour de justice de l'Union européenne du 18 décembre 2019 (C-666/18, IT Development contre Free Mobile), la Cour de cassation a jugé le 5 octobre 2022 (1re chambre civile, n° 21-15.386) que le titulaire de droits sur un logiciel pouvait agir en contrefaçon contre son licencié. Sur renvoi, la cour d'appel de Paris a condamné Orange le 14 février 2024 pour non-respect de la licence GNU GPL v2 sur la bibliothèque Lasso de la société Entr'ouvert : environ 800 000 euros au total, dont 500 000 euros au titre des conséquences économiques négatives, 150 000 euros au titre des bénéfices réalisés et 150 000 euros au titre du préjudice moral.

Face à une contamination, quatre voies : remplacer le composant, acheter une licence commerciale quand le projet pratique la double licence, réécrire la fonctionnalité, ou publier le code concerné. Les deux premières se comptent en semaines, la troisième en mois, la quatrième est rarement acceptable pour un éditeur. J'ai détaillé les familles de licences dans l'article consacré aux risques juridiques de l'open source.

Les dépendances et la nomenclature logicielle

Le fichier de verrouillage des dépendances est la seule vérité exploitable. Un projet qui déclare trente dépendances directes en résout couramment plus d'un millier une fois les dépendances transitives résolues. Sans fichier de verrouillage, l'inventaire n'est pas reproductible et l'auditeur ne peut rien affirmer.

La nomenclature logicielle, ou SBOM, formalise cet inventaire dans un format lisible par machine, en général CycloneDX ou SPDX, généré à chaque construction du produit. Sa production n'est plus une simple bonne pratique. Le règlement (UE) 2024/2847 sur la cyberrésilience, entré en vigueur le 10 décembre 2024, impose aux fabricants de produits comportant des éléments numériques une documentation technique incluant une nomenclature couvrant au moins les dépendances de premier niveau. À compter du 11 septembre 2026 s'appliquent les obligations de signalement des vulnérabilités activement exploitées et des incidents graves, avec une alerte précoce sous 24 heures puis une notification sous 72 heures. Les obligations principales s'appliquent au 11 décembre 2027.

Le périmètre mérite une précision. Un service en ligne pur n'est pas, en principe, un produit comportant des éléments numériques au sens de ce règlement. En revanche, une application livrée au client, un agent installé chez lui, un composant embarqué ou une solution de traitement à distance nécessaire au produit entrent dans le champ. Beaucoup d'éditeurs français sont concernés par une de leurs briques sans l'avoir mesuré.

Pour un acquéreur, l'intérêt est double : la nomenclature donne la carte des licences, donc du risque de contamination, et celle des vulnérabilités héritées, versions en fin de support, failles connues jamais corrigées, composants abandonnés. La faille Log4Shell, révélée en décembre 2021, a montré qu'un composant enfoui à trois niveaux pouvait exposer un parc entier. Ne pas pouvoir produire cette carte est, en soi, un résultat d'audit.

Les secrets laissés dans l'historique

C'est le point le plus concret, et le plus souvent découvert. Clés d'API, jetons d'accès, mots de passe de base, clés privées : ces chaînes finissent dans un commit, sont retirées deux jours plus tard, et restent dans l'historique pour toujours.

L'ordre de grandeur est public. Le rapport annuel de GitGuardian sur la dispersion des secrets recense 28,65 millions de nouveaux secrets codés en dur dans des dépôts GitHub publics sur la seule année 2025, en hausse de 34 % sur un an. Plus parlant encore, 64 % des secrets valides détectés en 2022 l'étaient toujours début 2026, faute de rotation. Et les dépôts privés, ceux que l'on ouvre en audit, en contiennent environ six fois plus que les dépôts publics.

La détection porte sur l'intégralité des branches et de l'historique, pas sur la dernière version du code, avec des outils comme gitleaks ou trufflehog. Un git log -p -S sur un préfixe de clé retrouve la chaîne supprimée en quelques secondes. Effacer réellement un secret suppose de réécrire l'historique et de propager cette réécriture à tous les clones existants, ce qui n'est jamais complet. La seule remédiation qui vaille est la rotation.

Le sujet n'est pas que technique. Si un identifiant exposé donne accès à des données personnelles de production, l'exposition est une violation de données, à notifier à la CNIL dans les 72 heures au titre de l'article 33 du RGPD. Même logique pour les jeux de test issus d'un export de production et commités dans le dépôt. Quand des sous-traitants accèdent à ces environnements, l'article 28 s'applique, comme je l'explique dans le mode d'emploi du DPA pour un éditeur SaaS. Côté acquéreur, la règle est simple : tout secret trouvé est réputé compromis, et sa rotation devient un préalable au closing.

Le code généré par IA

La question figure désormais dans toutes les listes d'audit : quelle part de votre base de code a été produite avec un assistant de génération, avec quel outil, et sous quelles conditions d'utilisation ?

Trois sujets se cachent derrière. La protection : le droit d'auteur suppose une création originale portant l'empreinte de la personnalité de son auteur, ce qu'une production entièrement automatique n'offre pas. La titularité contractuelle : les conditions des fournisseurs de modèles divergent sur la propriété des sorties et sur les garanties en cas de réclamation d'un tiers. Le risque de reproduction, enfin : une sortie peut reprendre un extrait protégé, y compris sous copyleft.

La conséquence intéresse directement un éditeur. Garantir à un client la titularité pleine et entière de livrables largement générés est une promesse qu'on tient mal. La traçabilité change tout : étiqueter les demandes de fusion concernées, conserver les mentions d'assistance dans les messages de commit, tenir une politique interne d'usage. Ce n'est pas parfait, mais c'est la différence entre « nous ne savons pas » et « voici le périmètre, et voici comment il a été vérifié ». Le fond du sujet est traité dans l'article consacré à l'IA générative et au droit d'auteur.

Organiser l'audit sans se mettre à nu

Ouvrir son code à un acquéreur, surtout quand celui-ci est aussi un concurrent, est un acte à risque. Il se cadre.

D'abord un accord de confidentialité, signé avant tout accès. L'article 1112-2 du code civil prévoit que celui qui utilise ou divulgue sans autorisation une information confidentielle obtenue à l'occasion des négociations engage sa responsabilité. La règle existe donc sans contrat, mais la preuve du périmètre et du préjudice pèse sur la victime : l'écrit sert à la construire.

Ensuite un protocole écrit : ce qui est audité, par qui nommément, avec quels outils, ce qui sort de la salle (le rapport, jamais le code), la durée, le sort des copies. Les accès se donnent en lecture seule, sur un miroir figé du dépôt, avec des comptes nominatifs, une journalisation et une révocation automatique à la date de fin. On ne transmet jamais une archive complète par messagerie ou par un espace de partage grand public.

Quand l'acquéreur est un concurrent, la salle blanche s'impose : un tiers indépendant lit le code et ne remet que des conclusions, sans extrait. Le dispositif protège les deux parties, le vendeur contre la fuite, l'acquéreur contre le reproche, plus tard, d'avoir reproduit ce qu'il avait vu. Dans une intégration, l'équivalent est le séquestre du code auprès d'un tiers, avec des déclencheurs de libération écrits : défaillance, arrêt de la maintenance, procédure collective. Un séquestre dont personne n'a vérifié que le dépôt est à jour et compilable ne vaut rien.

Aux vendeurs, je conseille de préparer une salle de code avant d'ouvrir la salle de données : la liste des contributeurs avec, en face de chacun, le contrat qui justifie la titularité ; une nomenclature logicielle à jour ; un rapport de licences ; un rapport de détection de secrets avec les rotations effectuées ; une politique d'usage de l'IA. Cinq documents, qui changent la tonalité de la négociation, comme le reste de la préparation d'une opération dans une startup ou une entreprise innovante.

Ce que le rapport change dans la négociation

Un rapport d'audit ne se lit pas comme un bulletin de notes. Il se traduit en clauses. Cinq leviers, du plus doux au plus dur.

• Le prix, par une décote correspondant au coût estimé de la remédiation.
• La condition suspensive : obtenir avant closing la cession manquante d'un prestataire, ou remplacer le composant contaminant.
• Les déclarations et garanties spécifiques : titularité pleine des droits sur le code, absence de composant à copyleft fort dans le périmètre distribué, absence de réclamation de tiers, respect des obligations d'attribution.
• La garantie d'actif et de passif, avec son seuil de déclenchement, sa franchise, son plafond et sa durée, souvent plus longue en propriété intellectuelle que la garantie générale, parce que le risque se révèle tard.
• Le séquestre d'une fraction du prix, libérée par tranches à mesure que les remédiations sont constatées.

Un scénario chiffré vaut mieux qu'un principe. Base de code de 400 000 lignes, module de facturation appuyé sur une bibliothèque sous AGPL, produit livré en version installable chez trois grands comptes. Remédiation technique : remplacer la bibliothèque, six semaines, deux développeurs, de l'ordre de 60 000 euros de coût direct. Effet sur l'opération : 400 000 euros de prix séquestrés pendant dix-huit mois, une garantie spécifique de propriété intellectuelle plafonnée à 30 % du prix pendant cinq ans, un closing repoussé de deux mois. Le coût de la remédiation n'est jamais le vrai coût.

Le vendeur qui a dissimulé ce qu'il savait s'expose davantage. L'article 1137 du code civil qualifie de dol la dissimulation intentionnelle, par un contractant, d'une information dont il sait le caractère déterminant pour l'autre partie. La jurisprudence tend à écarter les plafonds et limitations de garantie en présence d'un tel comportement.

Symétriquement, un audit mené douze mois avant l'opération coûte une fraction de la décote qu'il évite. Les corrections lourdes, cession rétroactive auprès d'un ancien prestataire ou remplacement d'un composant, demandent du temps et de la négociation. Trois semaines avant un closing, elles ne se font plus : elles se paient.

Trois actions, une journée de travail pour un développeur, et vous saurez si votre base de code est cessible en l'état : sortez la liste des auteurs du dépôt et confrontez-la à vos contrats, générez la nomenclature de vos dépendances et lisez la colonne des licences, lancez une détection de secrets sur tout l'historique. Si vous préparez une cession, une levée ou une intégration, ou si un rapport d'audit vous inquiète, échangeons sur votre situation : je lis votre dépôt et vos contrats avec la double lecture, juridique et technique, qui manque à la plupart des audits.