Due diligence technique : auditer le code avant d'acheter ou d'investir dans une société logicielle

Points clés

• La due diligence technique répond à une question pour l'acquéreur ou l'investisseur : le logiciel fait-il ce que le vendeur annonce, peut-il suivre le business plan, et combien coûtera la correction de ce qui ne suit pas ?
• Les constats qui font bouger une opération portent rarement sur le style du code. Ce sont des trous dans la propriété intellectuelle, des problèmes de licences open source, des incidents de sécurité, une dépendance à des personnes clés et une dette technique qui bloque la feuille de route.
• En France et dans l'UE, le code écrit par des freelances ou des agences appartient à son auteur sauf cession écrite. Un vendeur incapable de produire ces cessions n'est peut-être pas propriétaire de ce qu'il vend.
• Un bon rapport ne se contente pas de lister les problèmes : il les chiffre. Ce qu'il faut corriger avant le closing, ce qu'il faut corriger la première année, et ce qui relève du contrat de cession.
• Les constats se traduisent généralement en ajustement de prix, conditions suspensives, garanties spécifiques, séquestre ou plans de rétention, rarement en abandon de l'opération.

La due diligence technique est une revue indépendante du produit, du code, de l'infrastructure et de l'équipe technique d'une société logicielle, menée avant une acquisition ou un investissement. Les due diligences financière et juridique vérifient les chiffres et les contrats ; la due diligence technique vérifie l'actif qui justifie généralement le prix. Ce guide s'adresse aux acquéreurs, investisseurs et conseils d'administration. Il couvre ce qu'une revue doit examiner, ce qu'il faut demander au vendeur, et la façon dont les constats se traduisent dans les termes de l'opération. Ce guide est pratique et ne constitue pas un conseil juridique : ce sont vos avocats qui décident comment les constats sont reflétés dans les actes.

Quand en avez-vous besoin ?

• Pour acquérir une société logicielle, ou une entreprise dont la valeur repose sur son logiciel.
• Pour investir dans une startup ou une scale-up dont le produit est l'actif principal.
• Pour racheter un produit ou un code hors cession de titres (cession d'actifs).
• Avant une fusion où deux plateformes seront réunies.
• Côté vendeur, pour trouver et corriger les problèmes avant l'équipe de l'acquéreur. Une vendor due diligence raccourcit souvent le processus et protège le prix.

Ce que couvre une due diligence technique

1. Propriété intellectuelle : le vendeur est-il propriétaire du code ?

C'est le domaine le plus susceptible de produire un constat grave, et celui que sautent le plus souvent les revues qui ne lisent que le code.

• La chaîne des droits. Qui a écrit le code ? Le travail des salariés appartient par défaut à l'employeur en droit français et européen, mais celui des freelances, des agences et des fondateurs avant l'immatriculation appartient à son auteur, sauf cession écrite. Demandez les contrats. Notre guide à qui appartient le code explique pourquoi payer le code ne suffit pas à en transférer la propriété.
• Les composants tiers et préexistants. Du code concédé par une ancienne agence, un ancien employeur ou un partenaire, avec ou sans licence écrite.
• Les licences open source. Un inventaire des dépendances et de leurs licences, et une vérification des licences copyleft (comme la GPL ou l'AGPL) utilisées d'une façon qui pourrait obliger la société à publier son propre code. Une nomenclature logicielle (SBOM) rend cela vérifiable ; des formats comme SPDX et la norme OpenChain (ISO/IEC 5230) décrivent comment les entreprises matures s'organisent. En France, l'APP propose un audit de propriété intellectuelle comprenant une analyse du code source pour détecter les composants open source non déclarés.
• Où sont le code et les comptes. Dépôts, domaines, comptes cloud et comptes des stores doivent appartenir à la société, pas à un fondateur ou à un ancien prestataire.

2. Architecture et capacité à grandir

• L'architecture permet-elle le business plan : dix fois plus d'utilisateurs, de nouveaux marchés, de nouveaux produits, une application mobile ?
• Où sont les goulets d'étranglement : conception de la base, serveur unique, intégrations synchrones, monolithe impossible à déployer par morceaux ?
• La technologie est-elle courante et maintenue, ou une niche sur laquelle il sera difficile de recruter ?
• Que faudrait-il pour l'intégrer aux systèmes de l'acquéreur ?

3. Qualité du code et dette technique

Pas « le code est-il joli », mais « combien coûte-t-il à l'entreprise ? »

• La couverture de tests sur les règles métier qui comptent.
• Le temps nécessaire pour livrer un changement, et la fréquence des régressions.
• Les zones que tout le monde craint de toucher, et pourquoi.
• Une estimation de l'effort pour corriger ce qui bloque la feuille de route, afin que la dette devienne un chiffre dans le modèle plutôt qu'une inquiétude vague.

4. Sécurité et protection des données

• Les incidents passés et leur traitement. Posez la question directement, et vérifiez si les clients ou les autorités ont été notifiés quand c'était requis.
• L'exposition actuelle : authentification, autorisation, gestion des secrets, vulnérabilités des dépendances, journalisation. Une revue au regard d'un référentiel reconnu comme l'OWASP ASVS la garde objective.
• Les données personnelles : ce qui est stocké, où, sur quelle base légale, avec quels sous-traitants, et si les mesures de sécurité attendues par l'article 32 du RGPD sont en place.
• Les tests d'intrusion : quand, par qui, et si les constats ont été corrigés.

5. Infrastructure, exploitation et coûts

• L'hébergement, des sauvegardes effectivement restaurées, la supervision, l'historique des incidents et la disponibilité.
• Le coût du cloud et son évolution avec le nombre de clients. Une marge saine au volume actuel peut disparaître au volume du business plan.
• La dépendance à des fournisseurs coûteux à quitter.

6. Équipe et organisation

• Le risque de personne clé. Quelle part du système n'existe que dans une ou deux têtes ? Que se passe-t-il si le CTO ou un ingénieur fondateur part après le closing ?
• Les freelances et sous-traitants qui travaillent sur le cœur du produit, et à quelles conditions. Voir notre guide pour repérer les équipes juniors et la sous-traitance cachée.
• La documentation, l'intégration des nouveaux, la revue de code et les pratiques de déploiement.

Ce qu'il faut demander au vendeur

Une demande courte et précoce fait gagner des jours :

1. Un accès aux dépôts (en lecture), avec l'historique.
2. La documentation d'architecture et une vue d'ensemble de l'infrastructure.
3. La liste de toutes les personnes ayant contribué au code, avec leur statut (salarié, freelance, agence) et les clauses de propriété intellectuelle correspondantes.
4. La liste des dépendances ou la SBOM, et la politique open source s'il y en a une.
5. La documentation sécurité : rapports de tests d'intrusion, registre des incidents, registre des traitements.
6. Les factures d'hébergement des douze derniers mois.
7. La feuille de route produit, pour en tester la faisabilité.
8. Du temps avec les responsables techniques, sans l'équipe commerciale.

Comment les constats pèsent sur l'opération

Dans les cessions de titres françaises, beaucoup de ces points finissent dans la garantie d'actif et de passif ; pour les composants sous licence que la société ne peut pas posséder, le séquestre de code source est un autre outil. Vos avocats choisiront le mécanisme. Le rôle de l'équipe technique est de rendre chaque risque clair et de lui donner un coût.

Combien de temps cela prend

Cela dépend de la taille du produit et du rythme de l'opération. Une revue ciblée d'un seul produit peut se faire en quelques semaines ; une période d'exclusivité courte la comprime parfois à quelques jours, au détriment de la profondeur. Fixez le périmètre tôt : la propriété intellectuelle et la sécurité sont rarement les parties à sacrifier.

Questions fréquentes

Quelle différence entre due diligence technique et audit technique ? Un audit technique aide un propriétaire à améliorer son propre système. La due diligence technique sert un acquéreur ou un investisseur qui doit décider : elle pèse les risques de propriété intellectuelle, d'équipe et de coût en plus du code, et se conclut par des recommandations pour l'opération plutôt que par une liste de tâches.

Le vendeur nous laissera-t-il lire le code ? En général oui, sous accord de confidentialité et souvent dans un environnement contrôlé. Un vendeur qui refuse tout accès technique, c'est déjà un constat.

Le vendeur doit-il commander sa propre revue d'abord ? Souvent oui. Une vendor due diligence trouve les problèmes quand il est encore temps de les corriger, et un rapport propre soutient le prix.

Pouvez-vous auditer un code dans une technologie que vous n'utilisez pas au quotidien ? Les volets propriété intellectuelle, sécurité, infrastructure et équipe dépendent peu de la technologie. Pour le code lui-même, demandez à tout auditeur quelles technologies il maîtrise et quand il ferait appel à un spécialiste.

---

FNB Solutions réalise des audits techniques et des due diligences pour les acquéreurs, investisseurs et vendeurs de logiciels web. Voir notre offre d'audit technique ou contactez-nous pour cadrer une revue.

Sources

• Code de la propriété intellectuelle sur Légifrance, articles L113-9 et L131-3
• CISA, Software Bill of Materials (SBOM)
• SPDX, standard ouvert de nomenclature logicielle
• OpenChain, conformité des licences ISO/IEC 5230
• APP, audit de propriété intellectuelle
• OWASP Application Security Verification Standard
• Règlement (UE) 2016/679 (RGPD), article 32