Due diligence technique : ce que l'investisseur va chercher dans votre code

Ce qu’il cherche, et ce qu’il ne cherche pas#

Un investisseur qui commande une due diligence technique n’ouvre pas votre code pour juger s’il est élégant. Cela lui est parfaitement égal.

Il cherche trois choses, et trois seulement :

1. Ce qu’il achète, réellement. Le produit fait-il ce que le pitch prétend ? À quel prix ?
2. Ce qui peut lui exploser à la figure. Un risque juridique, une dépendance mortelle, une faille béante.
3. De quoi négocier. Chaque constat devient un argument de prix, une clause de garantie, une condition suspensive.

Comprendre cela change tout. Parce que cela vous dit où il va regarder, et donc où vous devez avoir regardé avant lui.

C’est le cousin de l’audit technique, avec un commanditaire différent — et cette différence change les priorités.

1. La propriété du code — le tueur numéro un#

C’est là que les opérations meurent, et c’est ce qui surprend le plus les dirigeants.

En droit français, la cession des droits sur un logiciel n’est jamais automatique. Elle doit être écrite et explicite. Avoir payé un développement ne fait pas de vous le propriétaire du code.

L’investisseur va donc demander, pour chaque personne ayant écrit une ligne :

• Les salariés : le code produit dans le cadre du contrat de travail est en principe dévolu à l’employeur, mais les contrats mal rédigés existent.
• Les prestataires et freelances : sans clause de cession, ils restent titulaires de leurs droits. Combien en avez-vous eu ? Avez-vous les contrats ?
• Les stagiaires, les alternants, l’ami qui a rendu service au début. Ce sont eux qui posent problème, parce que personne n’a signé quoi que ce soit.
• Et le cas le plus délicat : le fondateur qui est parti, et dont le code est partout.

Un seul trou dans cette chaîne, et l’investisseur ne sait plus ce qu’il achète. C’est le genre de problème qui ne se répare pas avec un chèque — et c’est pour ça qu’il tue.

Nous avons consacré un article entier à ce sujet : développement informatique et propriété du code source.

2. Les licences des dépendances#

Votre logiciel s’appuie sur des dizaines, parfois des centaines de bibliothèques écrites par d’autres. Chacune a une licence. Et toutes ne sont pas compatibles avec un usage commercial fermé.

Certaines licences dites « contaminantes » imposent, si vous distribuez le logiciel, de publier votre propre code sous la même licence. Si l’une d’elles s’est glissée dans un produit que vous vendez, l’investisseur veut le savoir avant de signer, pas après.

Ce point ne demande pas un juriste pour être dégrossi : il demande un inventaire. Et cet inventaire, personne ne l’a jamais fait.

3. La dépendance aux personnes#

Question posée sans détour : si cette personne part demain, que se passe-t-il ?

Un système qu’une seule personne comprend est un système que l’investisseur valorise mal — parce qu’il achète, en réalité, un contrat de travail qu’il ne contrôle pas.

Il regardera l’historique du dépôt de code. Il verra très vite si tout a été écrit par une seule main, sans relecture, sans transmission. Ce signal est plus parlant que mille lignes lues.

C’est aussi ce qui explique une clause fréquente : le maintien des fondateurs pendant deux ou trois ans après l’opération. Vous ne vendez pas seulement un produit ; vous vendez votre présence.

4. La dette technique, mais pas comme vous croyez#

L’investisseur sait qu’il y a de la dette. Il y en a partout, y compris chez les meilleurs. Ce n’est pas un scandale.

Ce qu’il veut savoir, c’est combien elle coûte :

• Combien de temps faut-il pour livrer une évolution simple ?
• Quelle proportion de l’effort part en correctifs plutôt qu’en nouveautés ?
• Le rythme de livraison ralentit-il avec le temps ?

Une dette qui ne ralentit rien est une non-information. Une dette qui double le coût de chaque évolution est un facteur de valorisation — au sens où elle la fait baisser.

5. La sécurité et les données personnelles#

Pas un test d’intrusion. Un examen de la surface et de la conformité : ce qui est exposé, où sont les secrets, quelles données personnelles sont traitées, sous quelle base légale, avec quelle durée de conservation.

Une faille se corrige. Une non-conformité structurelle sur les données — collecter sans base légale, conserver indéfiniment, sous-traiter hors UE sans encadrement — est un passif. Et un passif se déduit du prix.

6. L’infrastructure et ses coûts#

Ce qui est payé chaque mois, et ce qui grossira avec le nombre d’utilisateurs.

L’investisseur projette. Si votre coût d’infrastructure croît linéairement avec vos clients, votre marge ne s’améliorera jamais avec l’échelle — et c’est un problème de modèle économique, pas de technique.

Le tableau de ce qui tue, et de ce qui se négocie#

La dernière ligne mérite d’être lue deux fois. On ne vous reprochera pas un code laid. On vous reprochera de ne pas savoir à qui il appartient.

Comment s’y préparer : faites-la avant#

Le meilleur moment pour découvrir vos problèmes, c’est avant que l’investisseur ne les découvre.

Un dirigeant qui découvre un trou dans la chaîne de cession en même temps que l’acheteur négocie en position de faiblesse. Un dirigeant qui l’a documenté, chiffré, et qui arrive avec un plan de remédiation garde la main — et, souvent, garde le prix.

Concrètement, six mois avant : rassemblez les contrats de cession de tous ceux qui ont codé. Inventoriez les licences. Documentez ce qui tourne. Réduisez la dépendance aux personnes — ce qu’une seule personne sait doit devenir ce que l’entreprise sait.

Rien de tout cela n’est de la technique. C’est de la direction.

---

Nous menons des audits techniques en préparation d’opération, et nous siégeons au comité stratégique de structures qui lèvent. Si une échéance approche, le bon moment pour regarder, c’est maintenant : parlons-en.