Due diligence technique : le vrai red flag

Quand un fondateur entend « due diligence technique », il pense « il va falloir nettoyer le code ». Mauvaise cible. Les investisseurs savent qu'à ce stade, aucun code n'est propre. Ce qu'ils cherchent est ailleurs : est-ce que votre fonction technique survit au départ de la personne qui tient tout dans sa tête ?

J'ai vu une startup dont le lead dev a brillé pendant toute la réunion d'audit. Il répondait à chaque question, expliquait son architecture de mémoire, défendait chaque choix avec une aisance impressionnante. L'investisseur a reculé. Pas malgré cette performance : à cause d'elle. Ce qu'il avait compris en regardant ce virtuose dérouler une architecture que personne n'avait documentée, c'est que la fonction technique de l'entreprise, c'était lui. Une seule personne.

Ce qu'une due diligence regarde vraiment

Une due diligence ne note pas votre code comme une copie d'examen. En seed ou en série A, les investisseurs ont vu assez de bases de code pour savoir que tout est imparfait à ce stade. Leur travail, c'est de chiffrer un risque.

L'audit couvre plusieurs angles : la sécurité, la propriété intellectuelle, la dette technique, la capacité à scaler. Mais une seule catégorie fait vraiment capoter les deals, et c'est celle que vous ne pouvez pas corriger pendant les trois semaines de l'audit : la dépendance à une seule personne.

Le code n'est qu'un indice. Quand un investisseur le lit, sa vraie question n'est pas « est-ce propre », c'est « quelqu'un d'autre pourrait-il reprendre la main ». Ce n'est pas l'inspection des murs d'une maison. C'est de savoir si vous avez les clés, les plans, et quelqu'un qui sait comment la plomberie a été montée. Ou si tout ça vit dans la tête de celui qui a construit, et qui peut partir demain.

Le vrai tueur de deal

Ce n'est pas la dette technique qui fait fuir un investisseur. C'est de découvrir qu'elle vit dans une seule tête.

Je vais être direct : en due diligence, votre meilleur développeur peut être votre plus gros risque. Pas parce qu'il est mauvais, au contraire. Le problème n'est pas d'avoir un développeur exceptionnel. C'est que personne d'autre ne puisse reprendre son travail. Une fonction qui exige un virtuose pour être comprise casse le jour où le virtuose s'en va.

Et ça a un prix, fixé par l'investisseur, pas par vous. Quand un fonds découvre une dépendance critique de ce type, il a trois réponses possibles : baisser la valorisation pour pricer le risque, exiger un plan de remédiation en condition suspensive avant de débloquer les fonds, ou passer son chemin. Aucune ne joue en votre faveur.

Le même constat peut pourtant raconter deux histoires. « Tout repose sur une personne » est fatal. « Voici comment on a réduit cette dépendance ces six derniers mois » devient une preuve de maturité. Ce que l'investisseur achète, ce n'est pas l'absence de défauts. C'est une équipe qui voit ses fragilités et démontre qu'elle sait les traiter.

Ça se prépare avant, pas pendant

Le piège, c'est le calendrier. La plupart des fondateurs découvrent leur problème de dépendance à trois semaines d'un process qui en dure six. Trop tard pour le corriger, juste assez tôt pour perdre la main sur le récit. Transformer une tête en fonction ne s'improvise pas sous pression. C'est lent, peu glorieux, et c'est exactement le genre de chantier qu'on repousse quand on court vers une levée.

À quoi ça ressemble concrètement ?

• Une documentation qui permet à un tiers de reprendre. Pas les notes perso du dev, du savoir réellement transmissible.
• Au moins deux personnes capables de déployer en production, de comprendre les choix d'architecture et de gérer un incident critique.
• Une propriété du code propre. Et voici le red flag que personne ne voit venir : la cession de droits d'un freelance embauché il y a deux ans, jamais signée, qui fait qu'une partie de votre produit ne vous appartient pas légalement.
• Des accès aux systèmes (code, infra, secrets) partagés proprement, pas concentrés sur un seul individu.

Rien de tout ça n'est spectaculaire. Tout prend des mois. C'est précisément pour ça que ça commence avant.

Et ce n'est pas un sujet à déléguer vers le bas, au développeur lui-même. Ce serait demander au point unique de défaillance d'organiser son propre remplacement. C'est un arbitrage de dirigeant : soit vous avez une fonction, soit vous avez une personne. Si vous ne tranchez pas avant, vous l'apprendrez dans la salle d'audit, face à ceux qui décident de votre valorisation.

Faire ce travail est une des raisons d'être d'un CTO externalisé. Construire le produit n'en est qu'une moitié. L'autre, c'est de transformer une compétence individuelle en fonction d'entreprise : celle qui survit au départ de la personne.

Un test simple pour savoir où vous en êtes. Si votre responsable technique disparaissait pendant trente jours : qui déploie en production ? Qui comprend les choix d'architecture ? Qui gère un incident à trois heures du matin ? Qui détient les accès ? Si vous hésitez sur une seule réponse, votre due diligence a déjà commencé. Vous êtes juste le seul à ne pas encore le savoir.

Ce qu'il faut retenir

• Une due diligence technique mesure à quel point votre tech dépend d'un individu, bien plus que la propreté de votre code.
• Le développeur indispensable est un risque : non parce qu'il est mauvais, mais parce que personne d'autre ne peut reprendre.
• Cette dépendance a un coût, et c'est l'investisseur qui le fixe : valorisation, condition suspensive, ou abandon.
• Ça se construit des mois avant la levée, jamais pendant.

Questions fréquentes

Qu'est-ce qu'une due diligence technique lors d'une levée ?

C'est l'audit mené par les investisseurs après la lettre d'intention, pour vérifier que la réalité technique tient ses promesses. L'objectif n'est pas de juger la qualité du code, mais d'évaluer le risque, dont la capacité de l'entreprise à fonctionner si une personne clé part.

Quels red flags techniques font échouer une levée ?

Rarement le code imparfait, que les investisseurs anticipent. Plus souvent : la dépendance à une seule personne, une architecture que personne d'autre ne comprend, une propriété intellectuelle mal cédée, une sécurité bricolée. Le point commun, c'est qu'un tiers ne peut pas reprendre la main.

Combien de temps avant une levée faut-il s'y préparer ?

Six mois est un minimum raisonnable. Les problèmes de dépendance et de documentation ne se corrigent pas dans les dernières semaines. Ils se construisent en amont, pendant que vous contrôlez encore le récit.

Conclusion

Le bon moment pour repérer ce qui repose sur une seule tête, c'est maintenant, pendant que vous pouvez encore agir. C'est tout l'objet d'un diagnostic pré-due diligence : construire la fonction qui vous rend remplaçable, au bon sens du terme. Parlons-en sur un appel de 30 minutes.

Une levée ne crée pas vos fragilités. Elle les expose. Si votre fonction technique tient encore sur une seule personne, l'investisseur le verra. La seule question, c'est de savoir si vous l'aurez vu avant lui.