Due diligence technique :
savoir ce que vaut
vraiment le code.
Un investisseur s'apprête à mettre de l'argent dans une technologie qu'il ne peut pas lire. Un fondateur s'apprête à faire examiner cinq ans de développement en trois semaines. Dans les deux cas, la question est la même : qu'est-ce qui casse si ça marche ?
Le code est devenu la principale zone d'ombre des opérations.
Dans une levée de fonds, presque tout est vérifiable par un tiers : les comptes par un expert-comptable, les contrats par un avocat, le marché par des données publiques. Le code, lui, reste souvent pris pour argent comptant sur la base d'une démonstration produit et de la confiance accordée à l'équipe.
Or c'est précisément là que se logent les risques les plus coûteux à découvrir après signature : une architecture qui ne tiendra pas la croissance promise dans le plan, une dépendance critique à une seule personne, des données personnelles traitées sans base légale, ou du code dont la propriété n'a jamais été formellement cédée par un prestataire.
La due diligence technique consiste à lever cette zone d'ombre avant que la décision ne soit prise, pas après.
Ce que la due diligence technique examine
Architecture et capacité à tenir la trajectoire
- Le produit actuel supporte-t-il l'ordre de grandeur d'utilisateurs annoncé dans le plan à trois ans, ou faut-il le réécrire pour y arriver ?
- Points de contention structurels : base de données, traitements synchrones, dépendance à un service tiers unique.
- Coût d'infrastructure rapporté à l'usage — un modèle économique peut être démenti par sa facture technique.
Sécurité et données personnelles
- Contrôles d'accès réellement appliqués côté serveur, et non uniquement dans l'interface.
- Secrets et clés d'API exposés dans le code ou dans l'historique du dépôt.
- Traitement des données personnelles : ce que le produit collecte réellement, comparé à ce que la politique de confidentialité annonce.
- Un incident de sécurité survenu après l'investissement se paie sur la valorisation, et parfois sur la réputation de l'investisseur.
Dette technique et dépendances
- Dépendances non maintenues, versions en fin de support, vulnérabilités connues non corrigées.
- Licences des composants open source utilisés : certaines imposent des obligations incompatibles avec un produit propriétaire.
- Couverture de tests et capacité de l'équipe à livrer sans casser l'existant.
Facteur humain et propriété du code
- Concentration du savoir : combien de personnes comprennent réellement les parties critiques du produit ?
- Documentation permettant à un nouvel arrivant d'être opérationnel.
- Cession effective des droits sur le code écrit par des freelances ou des prestataires — un point régulièrement négligé, et bloquant lors d'un rachat.
Le cas particulier des produits construits avec l'IA
Une part croissante des startups qui lèvent aujourd'hui présentent un produit développé pour partie avec Cursor, Claude Code, Lovable ou Bolt. C'est une évolution normale, et ce n'est pas en soi un défaut : ces outils permettent d'atteindre un produit fonctionnel bien plus vite.
Mais cela déplace la question. Le rapport GenAI Code Security 2025 de Veracode, qui a analysé 80 tâches de développement sur plus de 100 modèles, relève qu'une faille de sécurité connue est introduite dans 45 % des cas. Un audit généraliste, qui vérifie surtout la présence de bonnes pratiques d'organisation, ne repère pas ce type de problème.
C'est la spécialité d'Avisers, et le principal différenciateur de cette mission : savoir lire une base de code générée, distinguer ce qui a été réellement conçu de ce qui a été accepté tel quel, et vérifier que les contrôles critiques existent ailleurs que dans l'interface. Voir aussi l'audit d'application IA et l'audit sécurité Lovable et Supabase.
Côté fondateur : se préparer avant d'être examiné
La plupart des fondateurs découvrent les faiblesses de leur produit pendant la due diligence, dans le pire moment possible : quand la découverte alimente une renégociation. Faire l'exercice en amont change la nature de la conversation.
- Ce qui est corrigé avant n'apparaît pas au rapport de l'investisseur.
- Ce qui ne peut pas être corrigé à temps est annoncé par vous, avec un plan et un chiffrage — cela devient une preuve de maîtrise plutôt qu'une mauvaise surprise.
- Les questions techniques posées en comité d'investissement trouvent des réponses documentées.
Le livrable
La contrainte du rapport est qu'il doit être lu par deux publics aux attentes opposées : un investisseur qui a besoin d'une décision, et une équipe technique qui a besoin d'instructions.
- Synthèse décisionnelle — les risques classés par gravité, formulés en conséquences business et non en termes techniques.
- Constats détaillés — pour chacun : où, pourquoi c'est un risque, et l'ordre de grandeur de l'effort de correction.
- Restitution en visio — pour répondre aux questions des deux publics, ensemble ou séparément.
Ce que cette mission n'est pas
- Ce n'est pas une valorisation. Avisers évalue un risque technique, pas le prix d'une société.
- Ce n'est pas une due diligence juridique ou financière. Les contrats, la structure du capital et les comptes relèvent d'un avocat et d'un expert-comptable.
- Ce n'est pas un pentest. L'audit se fait en lecture seule, sans exploitation offensive — voir audit de sécurité ou pentest.
- Avisers n'intervient jamais des deux côtés d'une même opération.
Due diligence technique — questions fréquentes
Qu'est-ce qu'une due diligence technique ?
C'est l'examen indépendant de la technologie d'une entreprise avant un investissement, un rachat ou une entrée au capital. Il porte sur le code, l'architecture, la sécurité, la dette technique, les dépendances et la propriété intellectuelle du code. L'objectif n'est pas de juger la qualité du travail des développeurs, mais d'évaluer un risque : que se passe-t-il si cette base de code doit supporter dix fois plus d'utilisateurs, ou si son auteur principal part ?
Qui commande une due diligence technique ?
Le plus souvent l'investisseur ou l'acquéreur, qui veut vérifier ce qu'il achète. Mais de plus en plus de fondateurs la commandent eux-mêmes en amont, pour corriger les points faibles avant que l'investisseur ne les découvre. Une faille trouvée par le fondateur se corrige ; la même faille trouvée par l'investisseur devient un argument de négociation sur la valorisation.
Combien de temps prend une due diligence technique ?
Le cadrage dépend de la taille du code et du nombre de surfaces à couvrir. Le calendrier est fixé avec vous avant de démarrer, en fonction de la date de votre closing : c'est le facteur contraignant dans ce type de mission.
Le rapport est-il compréhensible par un investisseur non technique ?
C'est la contrainte principale du livrable. Chaque constat est formulé en risque business : ce qui peut arriver, avec quelle probabilité, et ce que coûterait la correction en temps de développement. Les détails techniques sont fournis en annexe pour l'équipe qui devra corriger.
Auditez-vous les applications dont le code a été généré par IA ?
C'est une spécialité d'Avisers. De plus en plus de startups présentent en levée un produit construit avec Cursor, Claude Code, Lovable ou Bolt. Ces bases de code posent des questions spécifiques qu'un audit généraliste ne pose pas : cohérence de l'architecture, contrôles d'accès réellement appliqués côté serveur, et traçabilité de ce qui a été écrit par un humain.
Intervenez-vous côté investisseur ou côté startup ?
Les deux, mais jamais sur la même opération. L'indépendance du regard est ce qui donne sa valeur au rapport : intervenir des deux côtés d'une même transaction la détruirait.
Un closing approche ?
Parlons-en 30 minutes.
Diagnostic gratuit et sans engagement. On cadre le périmètre, le calendrier et ce qui est réaliste d'ici votre échéance.
→ Demander un devis