Due Diligence Technique

La réalité technique peut faire ou défaire un deal.

Vous êtes sur le point d’investir dans une entreprise. Le deck est convaincant. Les chiffres tiennent. Mais le produit tourne sur un système que personne en dehors de l’équipe fondatrice ne comprend vraiment — et le CTO dit que tout est “sous contrôle.”

C’est le cas ?

La dette technique n’apparaît pas toujours dans les états financiers. Une infrastructure fragile ne se lit pas dans le P&L. Une codebase tenue à bout de bras par un développeur critique qui pourrait partir — c’est un risque qui appartient à la due diligence, pas aux surprises post-closing.

C’est à ça que sert la Due Diligence Technique.

Pour qui

• Investisseurs et fonds qui évaluent une société avant de signer
• Acquéreurs qui ont besoin de comprendre ce qu’ils achètent réellement côté technique
• Fondateurs qui préparent une levée de fonds et veulent connaître leurs vulnérabilités avant que les investisseurs ne les trouvent

Le rapport est rédigé pour être lu par des décideurs non-techniciens. Pas de jargon. Des conclusions claires. Des chiffres actionnables.

Ce qui est passé en revue

Qualité du code et dette technique Le codebase est-il maintenable ? Quelle part a été écrite dans la précipitation et jamais nettoyée ? Y a-t-il des vulnérabilités de sécurité critiques ? Combien coûte la correction de la dette ?

Infrastructure et opérations Quel est le coût réel de fonctionnement ? Est-ce robuste — ou y a-t-il un single point of failure qui attend de se déclencher ? Quelles sont les dépendances externes et les risques de vendor lock-in ?

Équipe et processus Qui connaît le système ? Que se passe-t-il s’ils partent ? Comment le développement est-il organisé ? Quel est le processus de release, et fonctionne-t-il ?

Risques critiques et deal-breakers Qu’est-ce qui pourrait empêcher le business de scaler ? Quel est le risque technique le plus important qui n’est pas dans la data room ?

Estimation des coûts de modernisation Si des corrections sont nécessaires, combien cela coûtera-t-il ? Pas une approximation vague — une estimation structurée avec des hypothèses clairement posées.

Ce que vous obtenez

Un rapport écrit structuré avec :

• Résumé exécutif — le verdict en langage clair, pour les non-techniciens
• Matrice de risques — ce qui est critique, ce qui est significatif, ce qui est gérable
• Évaluation de la dette technique — ce qui existe, ce que ça coûte à porter, ce que ça coûte à corriger
• Revue d’infrastructure — fiabilité, coûts, dépendances
• Évaluation de l’équipe — risque de dépendance à une personne clé, maturité organisationnelle
• Estimations de modernisation — ce qu’il en coûterait de remettre le système au niveau
• Recommandations — continuer, renégocier, ou ne pas aller au bout

Le rapport est rédigé pour être lu par un DAF, un associé, ou un membre du conseil — pas seulement par un CTO.

Format et calendrier

Une semaine.

Accès nécessaire : le codebase (lecture seule), la documentation d’infrastructure, les schémas d’architecture s’ils existent, et une ou deux conversations techniques avec l’équipe de la cible.

Le rapport est livré en fin de semaine. Un appel de restitution est inclus pour passer les conclusions en revue.

Mission à distance par défaut. Sur site possible si la situation l’exige.

L’investissement

8 500 € — prix fixe

Une semaine de travail. Un rapport structuré. Un appel de restitution.

Pas de mauvaises surprises sur la facture.

Sur la confidentialité

La due diligence technique implique l’accès à du code et des systèmes sensibles. Je travaille sous NDA systématiquement. Le rapport est partagé exclusivement avec le commanditaire.

Je ne partage pas d’informations entre clients, et je n’utilise pas ce que je vois dans une mission pour informer le travail sur une autre.

Le timing

La due diligence a des deadlines. Si vous travaillez vers une date de closing, prenez contact tôt — je vous dirai honnêtement si je peux m’adapter à votre calendrier.