Due diligence technique avant levée

Une due diligence technique ne vérifie pas si votre code est parfait. Elle vérifie si vous savez exactement où votre produit peut casser et comment vous comptez y répondre.

Le plus mauvais moment pour découvrir un accès administrateur perdu, une base sans restauration testée ou une cession de droits absente, c'est au milieu du process. Pas parce qu'un investisseur attend une jeune startup sans dette. Il sait que le produit a été construit avec des compromis. En revanche, il veut savoir si ces compromis sont sous contrôle ou s'ils vont ralentir chaque euro investi.

La nuance change la préparation. Vous n'avez pas besoin de transformer votre SaaS en forteresse avant de lever. Vous devez être capable de dire : voici ce qui fonctionne, voici les zones fragiles, voici ce que nous avons décidé de traiter et voici le plan pour le reste.

Ce qu'une due diligence technique cherche à vérifier

Une due diligence ne commence pas par un concours de style sur le code. Elle cherche à relier votre promesse business à votre capacité technique réelle.

Si votre deck annonce que vous pouvez signer dix fois plus de clients, il faut comprendre ce qui se passe quand la charge augmente. Si vous vendez un produit qui traite des données sensibles, il faut vérifier qui y accède et comment vous réagissez à un incident. Si votre roadmap dépend de recrutements, il faut savoir si une nouvelle personne peut reprendre le système sans passer trois mois à le décoder.

Dans une revue pré-levée, je regarde d'abord les questions qui peuvent changer la conversation avec un investisseur :

• Le produit peut-il être déployé, surveillé et réparé sans improvisation ?
• Les données clients, les secrets et les accès critiques sont-ils maîtrisés ?
• L'entreprise détient-elle bien le code, les comptes et les contrats qui font tourner le produit ?
• La dette technique est-elle identifiée et reliée à un impact concret sur la roadmap, le coût ou le risque ?
• Une personne autre que le développeur historique peut-elle comprendre et faire évoluer les zones essentielles ?

Cette grille est plus utile qu'une liste de bonnes pratiques. Elle permet de séparer ce qui est acceptable à votre stade de ce qui peut casser la confiance.

Un monolithe, par exemple, n'est pas un red flag en soi. Pour beaucoup de startups, c'est même un choix raisonnable. Il le devient quand personne ne sait le déployer, quand une modification simple touche cinq parcours critiques, ou quand son seul mainteneur détient les accès et la connaissance. Le sujet n'est pas la technologie affichée dans votre stack. Le sujet est la dépendance qu'elle crée.

Les vrais red flags avant une levée

Les red flags les plus coûteux ne sont pas toujours les plus visibles dans une démo. L'interface peut être propre et le produit déjà vendu, tout en reposant sur des fondations fragiles.

Le premier concerne les accès. Un compte cloud ouvert au nom d'un ancien freelance, un nom de domaine géré depuis une boîte mail personnelle, des secrets copiés dans un document partagé : ce sont de petits raccourcis jusqu'au jour où ils ne le sont plus. L'entreprise doit pouvoir reprendre la main sur son code, son infrastructure, ses données et ses services tiers sans demander une faveur à qui que ce soit.

Le deuxième concerne les données. Il ne s'agit pas de promettre une certification que vous n'avez pas. Il faut pouvoir expliquer où vivent les données clients, qui peut les consulter, comment elles sont sauvegardées et ce que vous faites en cas d'incident. Une sauvegarde jamais restaurée n'est pas vraiment une stratégie de reprise.

Le troisième concerne la livraison du produit. Une pipeline manuelle peut suffire au début. Mais si le déploiement dépend d'une suite de commandes connues par une seule personne, chaque correctif urgent devient un risque. Même constat pour l'observabilité : si vous découvrez une panne par le message d'un client, vous n'avez pas encore la visibilité minimale pour grandir sereinement.

Enfin, il y a la propriété intellectuelle. C'est le point que beaucoup de fondateurs voient trop tard. Les contrats de prestataires prévoient-ils bien la cession des droits ? Les comptes GitHub, Vercel, Stripe ou les outils d'analytics appartiennent-ils à la société ? Une discussion sur la valorisation peut se tendre très vite si une partie du produit ne vous appartient pas clairement.

J'ai détaillé le risque de dépendance dans la due diligence technique et son vrai red flag. Il faut retenir une chose ici : la dette est rarement le problème. Une dette inconnue, sans responsable ni plan, l'est beaucoup plus.

Les documents à préparer

Le dossier technique n'a pas besoin d'être épais. Il doit répondre vite aux bonnes questions. Une page claire vaut mieux qu'un espace Notion rempli de notes contradictoires.

Préparez au minimum :

• une vue simple de l'architecture : application, base de données, hébergement, intégrations et flux sensibles ;
• la liste des outils et comptes critiques, avec leur propriétaire côté entreprise ;
• une matrice d'accès : qui peut administrer quoi et comment les accès sont révoqués ;
• les contrats et cessions de droits des salariés, freelances et agences ayant contribué au produit ;
• un résumé des sauvegardes, de la procédure de restauration et de la personne qui sait la lancer ;
• une liste courte des risques techniques connus, avec leur impact, leur priorité et la prochaine action.

Vous pouvez aussi joindre les quelques métriques qui prouvent que vous regardez votre produit vivre : disponibilité, erreurs applicatives, consommation d'une API coûteuse, délai de déploiement ou incidents marquants. Ne fabriquez pas de tableau de bord pour la circonstance. Montrez plutôt ce que l'équipe utilise vraiment pour décider.

Cet exercice recoupe une partie de la checklist d'audit technique startup. La différence est que l'audit peut explorer en profondeur. En due diligence, vous devez surtout rendre le risque lisible pour une personne qui n'a pas l'historique de votre équipe.

Ce qu'il faut assumer plutôt que cacher

Essayer de faire disparaître tous les défauts avant une levée est une mauvaise stratégie. Vous y laisserez du temps et vous risquez surtout de donner l'impression que personne ne pilote les arbitrages.

Assumez une zone fragile quand vous savez expliquer pourquoi elle existe, ce qu'elle peut coûter et ce qui la fera remonter dans les priorités. Par exemple : "Nous avons privilégié cette intégration rapide pour valider le marché. Elle ne tient pas encore une montée en charge importante. Nous avons chiffré son remplacement et le finançons dans les deux premiers mois après la levée." Ce n'est pas un aveu de faiblesse. C'est une décision explicite.

En revanche, ne banalisez pas un risque qui touche la continuité du produit, les données clients ou la propriété du code. Dire "on verra après la levée" sans responsable, budget ni échéance ne rassure personne.

Votre récit doit donc être simple : "nous savons ce qui ne va pas encore, et voici comment nous réduisons ce risque". Les fondateurs qui arrivent avec cette maturité gardent la main sur la discussion. Ceux qui découvrent le problème pendant les questions défensives la perdent.

Le plan des 30 jours avant les rendez-vous investisseurs

Trente jours ne suffisent pas à refaire votre architecture. Ils suffisent à remettre de l'ordre et à traiter les risques qui peuvent vraiment vous suivre dans la salle de réunion.

Semaine 1 : rendez les accès récupérables. Recensez les comptes critiques, transférez leur propriété à l'entreprise, supprimez les accès inutiles et activez une authentification forte partout où elle manque. Vérifiez aussi les moyens de paiement associés aux services essentiels.

Semaine 2 : cartographiez le produit. Faites dessiner à la personne qui connaît le mieux le système le chemin d'une donnée client, du navigateur à la base, puis jusqu'aux intégrations. Documentez aussi le déploiement et le rollback. Ce travail révèle souvent les angles morts plus vite qu'une longue revue de code.

Semaine 3 : choisissez trois risques maximum à corriger tout de suite. Une restauration non testée, une clé de production exposée ou une absence de cession de droits méritent cette place. Une convention de nommage incohérente, non. La méthode de priorisation des risques techniques doit rester liée à l'impact business, pas au confort de l'équipe.

Semaine 4 : mettez votre dossier au propre et répétez le récit. Un fondateur, un lead technique ou un CTO part-time doit pouvoir présenter les choix, les risques et le plan sans chercher les informations pendant la réunion. L'objectif n'est pas d'éviter toute question. C'est de répondre sans surprise.

Le résultat attendu tient en peu de livrables : une carte de l'architecture, une matrice d'accès, une liste priorisée de risques et un plan de remédiation daté. Vous aurez aussi gagné quelque chose de moins visible mais très utile : une équipe qui distingue enfin les dettes acceptables des risques qui empêchent de vendre, recruter ou lever.

Ce qu'il faut retenir

• Une due diligence technique cherche à mesurer un risque, pas à couronner la plus belle codebase.
• Les accès, les données, la capacité de déploiement, la propriété intellectuelle et la dépendance à une personne doivent être clairs avant le process.
• Un risque connu, priorisé et budgété se défend. Un risque découvert pendant l'audit subit la discussion.
• En trente jours, vous pouvez sécuriser les fondamentaux, produire les bons documents et clarifier votre récit.
• Le meilleur dossier ne masque pas les compromis. Il montre que vous savez lesquels vous avez faits et pourquoi.

Questions fréquentes

Quand faut-il lancer une due diligence technique ?

Idéalement, plusieurs mois avant de chercher des investisseurs. Si le process est déjà lancé, faites au moins une revue ciblée avant de partager un dossier technique. Vous ne corrigerez pas tout, mais vous éviterez de découvrir les risques les plus simples à traiter au pire moment.

Les investisseurs vont-ils lire tout notre code ?

Pas systématiquement, et rarement ligne par ligne. Leur équipe ou leur expert cherche surtout à vérifier les points qui soutiennent votre promesse : architecture, sécurité, données, capacité de livraison, dette et dépendances. La profondeur de la revue dépend du stade, du montant et du niveau de risque du produit.

Faut-il corriger toute la dette technique avant une levée ?

Non. Chercher à tout nettoyer est souvent un mauvais usage du temps avant une levée. Corrigez ce qui menace la disponibilité, la sécurité, les données, la capacité de livrer ou votre planning commercial. Pour le reste, expliquez le compromis et le plan.

Qui doit porter le dossier technique ?

Le fondateur doit comprendre les enjeux et pouvoir les raconter. Le dossier peut être préparé par le lead développeur, un CTO ou un CTO part-time, mais il ne doit pas vivre dans une seule tête. C'est précisément ce que la due diligence cherche à vérifier.

Conclusion

Une levée ne crée pas vos fragilités techniques. Elle les rend visibles à des personnes qui doivent décider si elles peuvent financer votre prochaine étape.

La bonne préparation n'est pas un grand chantier de nettoyage. C'est une revue lucide : reprendre les accès, rendre le produit transmissible, nommer les risques et choisir ceux qui doivent disparaître avant les rendez-vous. Vous arriverez avec un dossier plus clair et, surtout, avec une conversation que vous pouvez mener au lieu de la subir.

Si votre levée approche et que vous voulez vérifier ce qui pourrait bloquer la discussion, réservez une revue technique avant vos rendez-vous investisseurs.