Accueil/Ressources/Due diligence technique

Note

Qu'est-ce qu'une due diligence technique ?

Dans un deal, il est évident de regarder les comptes, les contrats et le cap table. La tech, elle, est souvent regardée en dernier — alors qu'elle représente parfois l'essentiel de ce qu'on achète.

Mis à jour le 26 août 2026

I. Ce que c'est

Une due diligence technique, c'est l'examen du système technique d'une entreprise par quelqu'un d'extérieur, payé par celui qui s'intéresse à l'asset.

Je la ramène toujours à trois questions :

• Est-ce que ce qui a été construit peut porter ce que le business plan promet ?
• Combien ça coûte à maintenir, et combien pour le remettre à niveau ?
• Qu'est-ce qui casse si telle personne s'en va ?

Lire le code, ouvrir l'infrastructure, parler aux ingénieurs : tout cela sert à répondre à ces trois questions avec des preuves plutôt qu'avec des impressions.

À la fin, il n'y a pas de certificat. Il y a un avis, des risques classés par ordre d'importance, et un commanditaire qui décide : continuer, renégocier, demander des garanties, ou s'arrêter là.

II. Ce que ce n'est pas

Trois confusions reviennent presque à chaque fois.

Un test d'intrusion

Un pentest cherche des failles exploitables, sur un périmètre donné, un jour donné. Je regarde autre chose : est-ce que cette entreprise est capable de produire du logiciel sûr (ou à quel point), et de continuer à le faire dans six mois. Les deux exercices se complètent. Il m'arrive d'ailleurs de recommander un pentest à l'issue d'un audit, quand le dossier le justifie.

Un audit financier ou juridique

La valorisation, les contrats, la propriété intellectuelle au sens juridique : ce n'est pas mon métier. Je fournis de la matière aux avocats et aux financiers — un chiffrage de remise à niveau, une dépendance critique, un risque de continuité — mais je m'arrête là.

Une note sur cent

Je n'en donne pas, parce qu'un score ne veut rien dire sans le contexte du deal. Une base de code médiocre dans une équipe qui sait la faire évoluer vaut mieux qu'une architecture élégante que trois personnes seulement comprennent. Ce qui compte, c'est ce que vous voulez faire de l'entreprise dans les vingt-quatre mois qui viennent. Je pratique le scoring sur des aspects précis de ma grille de lecture, mais ces scorings sont à lire comme des indices de confiance d'une confiance que je me forge par l'expérience.

Dernier point, qui tient moins à la définition qu'à la déontologie : je ne vends pas la remédiation de ce que je trouve. C'est ce qui rend l'avis utilisable dans une négociation. Imaginez si celui qui vous vend le rapport vous vend aussi la prestation qui aurait lieu derrière ? Cela interrogerait sur l'objectivité du rapport et des points soulevés...

III. Qui la commande

Trois situations. Le travail change assez peu ; ce que le commanditaire fait du rapport, par contre, peut changer beaucoup.

Un acquéreur ou un investisseur

Le cas le plus courant. Le rapport sert à la négociation, donc il doit conclure. « Six mois de deux ingénieurs pour tenir le plan de croissance » se transforme en ajustement de prix, en complément de prix conditionné ou en garantie. Un rapport qui décrit sans trancher ne pèse rien dans une salle de négociation. Il sert plutôt majoritairement à arbitrer ou la rédaction de conditions à l'opérateur, parce que justement, l'audit aura permis de mettre en lumière tel ou tel point.

Une entreprise qui lève ou qui se vend

C'est l'exercice inverse : savoir ce que l'audit d'en face va trouver, avant qu'il ne le trouve. L'idée n'est pas de cacher quoi que ce soit, mais d'arriver préparé. Une faiblesse que vous annoncez, chiffrée, avec un plan, se négocie. La même faiblesse découverte par l'acquéreur trois semaines avant le closing coûte beaucoup plus cher — et jette un doute sur tout le reste du dossier.

Un dirigeant ou un board, sans deal en cours

L'état des lieux. On me la demande souvent après l'arrivée d'un nouveau directeur technique, pour justifier un recrutement structurant, ou quand un board voit la roadmap glisser trimestre après trimestre sans comprendre pourquoi.

IV. Ce que je regarde

Quatre angles, un seul objet : le risque technique. Ils se recoupent volontairement.

Architecture & scalabilité

Est-ce que le produit tient la croissance prévue par le BP ? Je regarde les choix structurants, ce qu'ils coûteraient à défaire, et la courbe des coûts d'infrastructure. Quand la facture cloud croît plus vite que le chiffre d'affaires, le problème n'est plus technique, il est dans le modèle économique.

Code & dette technique

Qualité réelle du code, dépendances à risque, cohérence entre les projets, disparités des choix d'implémentation, effort de remise à niveau en jours et en euros. La dette existe partout, y compris chez les meilleurs. La question est de savoir si elle est connue, assumée, et proportionnée à l'âge de l'entreprise.

Sécurité & conformité

Gestion des données, surface d'exposition, pratiques de l'équipe. Je ne cherche pas à dresser la liste des vulnérabilités du jour ; elle sera périmée le mois prochain. Je cherche à savoir si l'organisation est capable de ne pas les réintroduire ou bien de créer les conditions pour s'organiser afin d'en faire un sujet maîtrisé.

Équipe & organisation

C'est l'angle qu'on saute le plus souvent, et celui qui produit les plus mauvaises surprises. Dépendance aux personnes clés, pratiques d'ingénierie, capacité réelle à exécuter la roadmap qu'on prête à l'équipe. Le code s'achète ; les gens qui savent le faire évoluer, non.

V. Comment ça se passe

Trois à six semaines selon le périmètre et la taille de la cible, en trois temps.

Cadrage

On définit ensemble le périmètre : les enjeux du dossier, vos points de vigilance, les accès nécessaires. C'est l'étape qui décide de l'utilité de tout le reste. Un audit lancé sans hypothèse à vérifier produit un inventaire ; un audit cadré produit un avis. NDA signé avant toute discussion.

Analyse

Revue du code et de l'infrastructure, entretiens avec l'équipe technique, et vérification de ce que la cible affirme. Ce dernier point compte autant que les deux autres. L'écart entre ce qui est présenté en réunion et ce que je lis dans le dépôt est déjà, en lui-même, un résultat d'audit.

Restitution

Un rapport écrit, puis une présentation orale. L'oral compte : c'est le moment où vous posez les questions que personne n'écrit dans un document, et surtout où la compréhension est assurée.

VI. Ce que je demande comme accès

Accès au sens credentials ou au sens visibilité sur un document. Cette liste peut parfois être longue mais c'est important de l'acter tôt car c'est l'obtention de la totalité des documents disponibles qui fluidifie le travail par la suite.

• Ex: le dépôt de code, avec tout son historique. L'historique compte autant que le code. Il montre qui a écrit quoi, quand l'équipe a changé, quelles zones sont retouchées sans arrêt, le volume d'intervention, le rythme de l'équipe, la répartition des intervention (nouvelles fonctionnalités, corrections de bugs, urgences en prod etc.). Un export du code sans historique, c'est la moitié de l'information en moins.
• Ex: l'infrastructure, en lecture seule. Ni accès administrateur, ni accès aux données. La configuration, la supervision et la facture suffisent — et la facture est souvent le document le plus instructif du dossier.
• Ex: les tickets et les incidents des douze derniers mois. C'est la mémoire objective de l'entreprise. Ce que l'équipe a vraiment fait de son temps est là ; ce qu'elle croit avoir fait est dans la présentation. Et parfois ... le simple fait qu'une organisation autour de ces sujets soit en place est déjà un signal en soi.
• Deux à quatre entretiens d'une heure, individuels. En groupe, j'obtiens la version officielle. Séparément, j'entends les désaccords possibles, difficilement assumables — et les désaccords sont de l'information.
• La documentation telle qu'elle est. Je ne la lis pas en entier. Son état — à jour, fantôme, inexistante — m'apprend déjà comment l'équipe travaille.

Tout se passe sous NDA, et la cible doit être prévenue. Auditer à l'insu de l'équipe technique dégrade le résultat pour un gain de discrétion illusoire : les ingénieurs comprennent toujours ce qui se passe.

VII. Ce que vous recevez

Un rapport écrit, construit pour être lu à deux niveaux : une synthèse qu'un board peut lire en dix minutes, et le détail qu'un CTO peut contester ligne à ligne. Chaque risque est classé — probabilité, impact, horizon — et chaque recommandation est chiffrée en effort. Une recommandation sans coût n'aide personne à arbitrer.

Un rapport qui aligne quarante constats sans les ordonner renvoie le travail d'analyse au lecteur. C'est pourtant ce qu'il achetait.

Puis la restitution orale, avec vous et, si vous le souhaitez, vos conseils. Le rapport est écrit pour pouvoir être transmis tel quel à un comité d'investissement.

VIII. Quand la lancer

Après la lettre d'intention, avant le closing. Avant la LOI, une cible n'ouvre pas ses accès, et elle a raison. Après le closing, les conclusions ne valent plus rien en négociation : elles deviennent un plan de travail, ce qui est utile, mais ce n'est plus le même exercice.

Prévoyez le délai d'obtention des accès. Il est presque toujours sous-estimé. Trois semaines annoncées en deviennent cinq quand les droits sur le dépôt arrivent le dixième jour ; ça se négocie au cadrage.

IX. Ce qui fait rater un audit

• Un périmètre flou. « Regardez si la tech est bonne » ne se vérifie pas. « Est-ce que cette plateforme passe de 5 000 à 50 000 clients sans réécriture » se vérifie.
• Des accès partiels. Sans historique du dépôt, sans production, sans les tickets, sans l'historique des incidents, la doc ... il ne reste que la parole de la cible. Ce n'est plus un audit, c'est un compte rendu.
• Une équipe non prévenue. Quand les ingénieurs découvrent l'audit le matin du premier entretien, ils se défendent au lieu d'expliquer. On perd ce qui a le plus de valeur : ce qu'ils savent déjà des faiblesses de leur système, et qu'ils disent volontiers quand le cadre est clair. Et parfois, quelques jours de préparation peut permettre de préparer l'asset à être vu de l'extérieur, ce n'est pas grave qu'il ne l'ait pas été sur l'étagère, l'important c'est ce qu'il vaut vraiment, pas à quel point la doc est belle, mais ça fait gagner du temps à l'audit et tout le monde y gagne en confort / échanges.
• Un auditeur qui vend la suite. Celui qui espère facturer la remédiation ne rend pas le même rapport. L'indépendance n'est pas un argument commercial, c'est une condition de validité.

X. Questions fréquentes

← Toutes les ressources