Technical due diligence : préparer l'audit tech de votre startup avant de lever

La technical due diligence est souvent la partie de la levée de fonds que les fondateurs préparent le moins, alors que c'est celle qui peut faire tomber le plus vite une valorisation. Le financier a bouclé le business plan, l'avocat a relu les statuts, puis un auditeur mandaté par le fonds demande l'accès au dépôt de code, la liste des contributeurs depuis la création et le dernier rapport de test d'intrusion. En quelques jours, des sujets techniques deviennent des clauses de garantie, des séquestres ou une décote.

Ce guide détaille ce que les investisseurs auditent réellement côté code, sécurité et propriété du logiciel, comment ces constats se traduisent en euros dans la négociation, et un rétroplanning de huit semaines pour arriver prêt. Chez DIGIFEC, cabinet d'expertise comptable dédié aux startups, nous voyons régulièrement des tours retardés par une cession de droits oubliée ou une facture cloud que personne n'avait analysée : l'essentiel se règle en amont.

Qu'est-ce qu'une technical due diligence et pourquoi les investisseurs la font-ils ?

Une tech due diligence est un audit indépendant de l'actif technologique d'une société, réalisé pour le compte d'un investisseur ou d'un acquéreur. Dans une startup SaaS ou deeptech, la technologie représente souvent l'essentiel de la valeur : le fonds doit donc vérifier que le produit existe tel qu'il est décrit, qu'il peut monter en charge et qu'il appartient bien à la société qui lève.

L'investisseur cherche à répondre à trois questions. La technologie tient-elle le plan de croissance ? Un produit qui fonctionne pour 50 clients mais qui devra être réécrit pour en servir 500 représente un coût caché que le business plan ne montre pas. Quels risques peuvent détruire de la valeur ? Faille de sécurité, fuite de données, litige de propriété intellectuelle, dépendance à une personne clé. Combien coûtera la correction ? Chaque constat est traduit en budget, en délai et, au final, en ajustement de prix ou de garanties.

La due diligence technology complète les autres audits du tour : financier, juridique, fiscal et social. Elle s'appuie sur les mêmes outils, en premier lieu une data room correctement structurée pour la due diligence, et sur des entretiens avec le CTO et les développeurs clés.

Technical due diligence, tech due diligence, audit de code : de quoi parle-t-on ?

Les termes se recoupent. L'audit de code est une composante : il examine la qualité, la maintenabilité et les vulnérabilités du code source. La technical due diligence est plus large : elle intègre l'infrastructure, la sécurité opérationnelle, la conformité des données, la propriété du logiciel, l'équipe et la roadmap. Dans la pratique, les fonds utilisent indifféremment « tech DD » ou « due diligence technology » pour désigner l'ensemble.

À quel moment de la levée intervient la tech due diligence ?

Dans un tour classique, l'audit technique démarre après la signature de la term sheet, pendant la période d'exclusivité, et avant la rédaction des documents définitifs (pacte d'associés, contrat d'investissement, garanties). C'est à ce moment que le fonds engage des frais d'audit et que les constats peuvent encore modifier les conditions négociées. Relisez donc attentivement les conditions suspensives de votre lettre d'intention : notre article sur comment décrypter et négocier la term sheet détaille les clauses qui renvoient aux résultats des audits.

L'intensité varie selon le stade :

• Pré-seed et seed : entretien approfondi avec le CTO, démonstration, quelques pièces (schéma d'architecture, contrats des développeurs). Les business angels s'arrêtent souvent là.
• Série A : audit formalisé, parfois externalisé à un cabinet spécialisé, avec accès en lecture au dépôt, scan automatique et questionnaire détaillé. Voir notre guide pour préparer un tour de série A.
• Séries B et suivantes, cession : audit complet, revue de sécurité, analyse des coûts d'infrastructure, entretiens avec plusieurs membres de l'équipe, et rapport écrit qui alimente les garanties d'actif et de passif.

Le bon réflexe consiste à considérer que la tech DD commence dès le premier rendez-vous : les questions d'un associé de fonds sont souvent celles de l'auditeur, en version courte.

Que regardent les auditeurs côté code et architecture ?

L'auditeur ne lit pas tout le code. Il cherche à évaluer la capacité du produit à évoluer sans réécriture coûteuse et la capacité de l'équipe à le maintenir. Il combine trois sources : des outils d'analyse statique lancés sur le dépôt, une revue manuelle de modules critiques et des entretiens.

Architecture et scalabilité

Premier document demandé : un schéma d'architecture à jour, qui montre les composants, les flux de données, les services tiers et les points de défaillance. L'auditeur vérifie ensuite que l'architecture est cohérente avec le plan de croissance. Un monolithe bien structuré n'est pas un problème à ce stade ; un monolithe sans frontières claires entre modules, où chaque évolution touche dix fichiers, en est un.

Qualité du code et dette technique

Les indicateurs observés sont classiques : couverture de tests sur les parties critiques, duplication, complexité des fonctions, respect de conventions, fréquence et taille des commits, présence de revues de code. La dette technique n'est pas disqualifiante en soi : toutes les startups en ont. Ce qui inquiète, c'est une dette non identifiée, non chiffrée et sans plan de remboursement. Une liste des chantiers connus, priorisée et estimée en jours, transforme un risque en sujet de roadmap.

Infrastructure, déploiement et coûts

Le fonds regarde la chaîne d'intégration et de déploiement continus, la séparation des environnements, la supervision et la capacité à restaurer le service après incident. Il croise aussi la technique avec la finance : coût d'hébergement par client, évolution de la facture cloud rapportée au revenu récurrent, engagements pluriannuels signés avec les fournisseurs. Un coût cloud qui croît plus vite que l'ARR dégrade la marge brute et donc la valorisation. Ces chiffres doivent être cohérents avec ceux de vos tableaux de bord financiers.

Sécurité et données personnelles : quels points sont vérifiés ?

La sécurité est le bloc où un seul constat peut suffire à faire suspendre un tour. L'auditeur vérifie l'existence de pratiques de base plutôt qu'une certification : un investisseur seed ne s'attend pas à une norme de sécurité certifiée, mais il refusera des secrets d'API stockés en clair dans le dépôt.

Sécurité applicative et opérationnelle

• Gestion des accès : comptes nominatifs, authentification forte sur les outils critiques, révocation des accès des anciens collaborateurs, principe du moindre privilège.
• Gestion des secrets : coffre-fort de secrets, rotation des clés, historique du dépôt purgé des identifiants exposés.
• Tests d'intrusion : date du dernier test, périmètre, vulnérabilités relevées et preuve de leur correction.
• Sauvegardes et continuité : fréquence des sauvegardes, test de restauration réel, plan de reprise documenté.
• Journal des incidents : incidents passés, analyse post-mortem et mesures prises.

Conformité RGPD et gestion des données

Dès que le produit traite des données personnelles, l'auditeur vérifie la conformité au RGPD. Les points examinés recoupent les obligations rappelées par l'administration sur les obligations RGPD des entreprises (Service-Public) : base légale des traitements, information des personnes, registre des traitements, mesures de sécurité proportionnées aux risques, encadrement de chaque sous-traitant par un contrat, et transferts hors Union européenne couverts par une décision d'adéquation ou des garanties appropriées.

L'auditeur demande aussi la procédure interne de gestion des violations de données, qui doit permettre de notifier la CNIL dans les conditions prévues par l'article 33 du RGPD. Les enjeux financiers sont réels : pour les manquements les plus graves, le plafond des amendes est porté à 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial, comme le rappelle la loi n° 2018-493 du 20 juin 2018 relative à la protection des données personnelles. Un fonds n'achète pas ce risque sans garantie.

Deux constats reviennent souvent : des données de production copiées en environnement de test sans anonymisation, et des outils SaaS tiers qui reçoivent des données clients sans contrat de sous-traitance.

Propriété du logiciel : la startup possède-t-elle vraiment son code ?

C'est le bloc le plus juridique de la tech due diligence, et celui où les fondateurs ont le plus de surprises. L'investisseur achète des titres d'une société dont la valeur repose sur un logiciel : il doit avoir la certitude que la société est titulaire des droits patrimoniaux sur ce logiciel, sans contestation possible.

Le cas des salariés

Pour les salariés, le Code de la propriété intellectuelle prévoit une dévolution à l'employeur : l'article L113-9 du CPI attribue à l'employeur les droits patrimoniaux sur les logiciels et leur documentation créés par les employés dans l'exercice de leurs fonctions ou d'après ses instructions, sauf dispositions statutaires ou stipulations contraires. L'auditeur vérifie donc que les développeurs ont bien un contrat de travail, que leurs fonctions incluent le développement et qu'aucune clause ne déroge à ce principe.

Freelances, agences et fondateurs

Cette dévolution ne joue pas pour les prestataires. Un freelance ou une agence qui a développé le MVP reste titulaire de ses droits tant qu'une cession n'a pas été signée. Et la cession doit être rédigée avec précision : selon l'article L131-3 du CPI, la transmission des droits de l'auteur suppose que chacun des droits cédés fasse l'objet d'une mention distincte et que son domaine d'exploitation soit délimité quant à son étendue, sa destination, son lieu et sa durée. Une clause générale du type « tous les droits sont cédés au client » expose à une contestation.

Le cas le plus fréquent dans les jeunes startups est celui du CTO cofondateur qui a écrit les premières versions du produit avant l'immatriculation ou sans contrat de travail. Il est associé, mais la qualité d'associé ne transfère aucun droit sur le code. Une cession ou un apport en bonne et due forme est indispensable.

Open source, licences et dépendances : le piège silencieux

Un produit SaaS moderne embarque des centaines de dépendances open source. C'est normal et les investisseurs le savent. Ce qu'ils vérifient, c'est que les licences de ces composants sont compatibles avec votre modèle de distribution.

Les licences dites permissives (MIT, BSD, Apache) imposent essentiellement de conserver les mentions de droits d'auteur et le texte de licence. Les licences copyleft (famille GPL, notamment l'AGPL conçue pour les usages en réseau) peuvent imposer de publier le code source des œuvres dérivées dans certaines conditions. Un composant copyleft modifié et intégré au cœur d'un produit propriétaire distribué, ou exposé en réseau dans le cas de l'AGPL, est un red flag classique.

La réponse attendue tient en trois livrables :

1. Un inventaire des dépendances (souvent appelé SBOM, software bill of materials) avec, pour chacune, sa version et sa licence, généré par un outil de scan.
2. Une politique d'usage de l'open source d'une page : licences autorisées, licences soumises à validation, licences interdites.
3. Un plan de remplacement pour les composants problématiques identifiés, avec un délai.

Équipe, process et dépendance aux personnes clés : la dimension organisationnelle

Le meilleur code ne vaut rien si personne ne peut le faire évoluer. L'auditeur consacre une part importante de son temps aux entretiens : avec le CTO, mais aussi avec un ou deux développeurs. Il cherche à mesurer la dépendance à une personne clé (le « bus factor »), la maturité des process et le réalisme de la roadmap.

• Documentation : README à jour, procédures de déploiement, runbooks d'incident, décisions d'architecture tracées.
• Process : revue de code systématique, gestion des tickets, rituels d'équipe, astreinte.
• Roadmap : cohérence entre les fonctionnalités promises dans le pitch deck, les effectifs prévus au business plan et la vélocité réelle de l'équipe.
• Rétention : les développeurs clés sont-ils intéressés au capital, avec un vesting adapté ? L'auditeur fait souvent le lien avec la politique de BSPCE.

La cohérence entre la roadmap et le plan de recrutement est un point où la finance et la tech se rejoignent. Si le business plan prévoit trois développeurs supplémentaires et que la roadmap en exige six, le fonds recalculera votre burn.

Comment chiffrer l'impact d'un red flag dans la négociation ?

Un constat d'audit se traduit toujours en argent, selon trois mécanismes : une décote de valorisation, un séquestre ou une garantie spécifique, ou un report du closing le temps de corriger. Le cas pratique suivant, construit sur des hypothèses illustratives, montre l'ordre de grandeur.

Cas pratique : SaaSly, éditeur SaaS B2B en série A

SaaSly réalise 2 millions d'euros d'ARR et négocie une levée de 6 millions d'euros sur une valorisation pré-money de 24 millions d'euros. Son burn mensuel net est de 250 000 €. L'audit technique révèle deux constats :

• le module de facturation, cœur du produit, a été développé par un freelance qui n'a jamais signé de cession de droits ;
• aucun test d'intrusion n'a été réalisé et des clés d'API figurent en clair dans l'historique du dépôt.

Le fonds propose : une décote de 5 % sur la pré-money pour le risque de propriété, soit 24 000 000 × 5 % = 1 200 000 € ; un séquestre de 10 % du montant levé pendant 12 mois pour financer la refonte sécurité, soit 6 000 000 × 10 % = 600 000 € immobilisés ; et le report du closing de deux mois, le temps de retrouver le freelance et de corriger les failles, soit 2 × 250 000 € = 500 000 € de trésorerie consommée avant l'arrivée des fonds.

Lecture : la décote de 1 200 000 € est définitive. Elle se traduit par une dilution supplémentaire pour les fondateurs : avec 6 millions levés, l'investisseur détient 6 / (24 + 6) = 20 % en post-money dans le scénario initial, contre 6 / (22,8 + 6) ≈ 20,8 % après décote. Le séquestre de 600 000 € n'est pas perdu mais n'est pas disponible pour la croissance, et les deux mois de retard consomment 500 000 € de runway. À l'inverse, une préparation menée en amont (cession signée avec le freelance, purge des secrets, test d'intrusion, documentation) aurait coûté de l'ordre de 45 000 € dans notre hypothèse. Pour approfondir le calcul de dilution, consultez notre article sur la valorisation pré-money et post-money.

L'écart total de près de 1,8 million d'euros (décote et séquestre, hors coût du retard) illustre la règle : un red flag découvert par l'investisseur coûte beaucoup plus cher qu'un point faible identifié, documenté et présenté par les fondateurs eux-mêmes avec son plan de correction.

Comment préparer votre technical due diligence en 8 semaines ?

La préparation suit la logique de l'audit : se mettre à la place de l'auditeur, identifier ses questions, et avoir la réponse documentée avant qu'il ne la pose. Le rétroplanning ci-dessous s'applique à une startup de série A qui part d'une situation peu documentée.

Checklist des pièces à réunir

1. Schéma d'architecture à jour et description des principaux composants.
2. Liste exhaustive des contributeurs au code depuis la création, avec leur statut (salarié, freelance, agence, fondateur, stagiaire).
3. Contrats de travail des développeurs et contrats de prestation avec clauses de cession conformes.
4. Actes de cession ou d'apport du code écrit par les fondateurs avant ou hors contrat.
5. Inventaire des dépendances open source avec licences et politique d'usage.
6. Dernier rapport de test d'intrusion et preuve de correction des vulnérabilités critiques.
7. Politique d'accès, de gestion des secrets et de sauvegarde, avec date du dernier test de restauration.
8. Registre des traitements, contrats de sous-traitance, cartographie des transferts de données.
9. Facture d'hébergement sur douze mois et coût d'infrastructure par client.
10. Roadmap à douze ou dix-huit mois, cohérente avec le plan de recrutement du business plan.
11. Liste de la dette technique connue, priorisée et estimée.
12. Journal des incidents de sécurité ou de disponibilité et post-mortems associés.

Ces pièces alimentent aussi les réponses aux questionnaires envoyés par les conseils de l'investisseur : notre article sur le questionnaire de due diligence et les questions posées en donne une vue d'ensemble, au-delà du seul volet technique.

Préparer le CTO aux entretiens

L'entretien avec le CTO pèse autant que les documents. Préparez une présentation courte de l'architecture, des choix techniques et de leurs raisons, de la dette connue et du plan de correction. L'auditeur apprécie la lucidité : reconnaître une faiblesse en expliquant comment elle sera traitée inspire plus confiance qu'un discours où tout est parfait.

Quelles sont les erreurs fréquentes à éviter ?

• Découvrir les sujets en même temps que l'auditeur. Un constat non anticipé affaiblit votre position de négociation, même s'il est mineur.
• Croire que l'actionnariat du CTO règle la propriété du code. Sans cession écrite, la société n'est pas titulaire des droits sur ce qu'il a développé hors contrat de travail.
• Signer des cessions trop vagues. Une cession qui ne précise pas les droits cédés, leur étendue, leur destination, leur lieu et leur durée reste fragile.
• Ouvrir un accès en écriture au dépôt. L'auditeur a besoin d'un accès en lecture, temporaire et tracé, sous accord de confidentialité.
• Présenter des métriques techniques incohérentes avec les chiffres financiers. Coûts cloud, nombre d'utilisateurs actifs et effectifs doivent se recouper avec le business plan et la comptabilité.
• Négliger les outils tiers. Chaque outil SaaS qui reçoit des données clients doit être couvert par un contrat de sous-traitance.

En résumé : la technical due diligence se prépare avant la term sheet

Une technical due diligence réussie ne repose pas sur un code parfait, mais sur un actif technologique maîtrisé, documenté et juridiquement propre. Les investisseurs auditent six blocs : architecture et code, infrastructure et coûts, sécurité, données personnelles, propriété du logiciel, équipe et process. Le bloc propriété est le plus fréquemment sous-estimé, alors qu'une seule cession manquante peut justifier une décote ou bloquer le closing.

Huit semaines de préparation suffisent généralement à transformer des red flags en points de roadmap présentés par les fondateurs eux-mêmes. Pour aligner vos métriques techniques avec votre business plan, chiffrer l'impact de la dette technique sur votre burn et structurer votre data room, découvrez l'accompagnement des startups en levée de fonds proposé par DIGIFEC.

À lire aussi

• Due diligence stratégique : comment sécuriser vos opérations d'acquisition et de levée de fonds ?
• Levée de fonds startup : guide juridique complet pour réussir votre tour de table
• Deck pitch : les slides qui convainquent un investisseur, exemple à l'appui
• Conseil en levée de fonds : guide juridique complet pour dirigeants et fondateurs