Quand un fondateur entend « due diligence technique », il pense qu'il va falloir nettoyer le code. Mauvaise cible. Les investisseurs savent qu'à ce stade, aucun code n'est propre. Ils veulent surtout savoir si votre fonction technique survivrait 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 et défendait chaque choix avec une aisance impressionnante. L'investisseur a reculé à cause de cette performance. En regardant ce virtuose dérouler une architecture que personne n'avait documentée, il a compris que toute la fonction technique tenait sur 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 la sécurité, la propriété intellectuelle, la dette technique et la capacité à scaler. Mais la dépendance à une seule personne fait vraiment capoter des deals. Trois semaines d'audit ne suffisent pas à la corriger.
Le code n'est qu'un indice. Quand un investisseur le lit, il cherche à savoir si quelqu'un d'autre pourrait reprendre la main. Il ne se contente pas d'inspecter les murs d'une maison. Il vérifie que vous avez les clés, les plans et quelqu'un qui comprend la plomberie. Sinon, tout vit dans la tête de celui qui a construit et qui peut partir demain.
Si vous voulez préparer le sujet avant d'entrer dans un process investisseur, j'ai détaillé les points à cadrer dans due diligence technique avant levée.
Le vrai tueur de deal
La dette technique ne fait pas fuir l'investisseur à elle seule. Découvrir qu'une seule personne la comprend, oui.
En due diligence, votre meilleur développeur peut devenir votre plus gros risque. Sa compétence n'est pas en cause. La fragilité vient du fait que personne d'autre ne peut 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 » prouve que l'équipe sait agir. L'investisseur n'achète pas une entreprise sans défauts. Il achète une équipe qui voit ses fragilités et les traite.
Ç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.
Ce travail n'a rien de spectaculaire et prend des mois. Il doit donc commencer tôt.
Ne déléguez pas ce sujet au développeur lui-même. Vous demanderiez au point unique de défaillance d'organiser son propre remplacement. Cet arbitrage appartient au dirigeant. Votre entreprise possède une fonction ou dépend d'une personne. Sans décision préalable, la salle d'audit tranchera à votre place.
Un CTO externalisé sert aussi à mener ce travail. Il ne construit pas seulement le produit. Il transforme une compétence individuelle en fonction d'entreprise, capable de survivre au départ d'une 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.