Due diligence technique en série A : ce que les investisseurs regardent vraiment (et ce que vous avez ignoré au seed)

Un fonds vous envoie une term sheet. Tout va bien, jusqu’au jour où son cabinet d’audit technique demande l’accès en lecture à votre dépôt Git, votre registre de traitements RGPD et la liste de vos dépendances open source. Trois semaines plus tard, la valorisation a baissé de 15 %, assortie d’un earn-out conditionné à un plan de remédiation. Vous n’aviez rien caché. Vous aviez juste construit comme la plupart des startups construisent au seed : vite, et sans imaginer que quelqu’un regarderait sous le capot.

La due diligence technique n’est pas un contrôle de conformité. C’est une évaluation du risque que représente votre dette accumulée pour la thèse d’investissement. Et ce risque, vous l’avez créé dix-huit mois plus tôt, à un moment où il était parfaitement rationnel de l’ignorer. Le problème, c’est que personne ne vous a dit que ces choix laissaient une trace.

Ce que la DD technique cherche vraiment à mesurer

Un investisseur série A ne finance pas votre code. Il finance votre capacité à transformer dix millions d’euros en une croissance défendable sur vingt-quatre à trente-six mois. La due diligence technique répond donc à une seule question, déclinée en sous-questions : qu’est-ce qui, dans cette stack et cette équipe, peut faire dérailler ce plan ?

Concrètement, l’auditeur cherche trois choses. D’abord, le risque de continuité : si votre CTO part demain, combien de personnes comprennent réellement le système ? Une architecture entièrement dans la tête d’un seul fondateur technique est un drapeau rouge, indépendamment de sa qualité. Ensuite, le coût de la scalabilité à venir : ce que vous présentez comme « il suffit d’ajouter des serveurs » cache souvent une base de données monolithique, des requêtes non indexées et un couplage qui transforme chaque nouvelle feature en chantier. Enfin, le passif juridique et réglementaire : une fuite de données après l’investissement, c’est le fonds qui se retrouve actionnaire d’un problème RGPD. Ils veulent en avoir le cœur net avant de signer.

Ce déplacement du regard est essentiel à comprendre. Au seed, votre interlocuteur évaluait votre vision et votre traction. En série A, il évalue votre fragilité opérationnelle. Et la fragilité ne se voit pas dans un pitch deck — elle se lit dans un historique de commits, une couverture de tests et un fichier .env qui traîne dans le dépôt.

Les quatre zones qui font dérailler une DD

Sur le terrain, les blocages se concentrent presque toujours aux mêmes endroits. Les connaître à l’avance change tout, parce que la plupart se corrigent en quelques semaines si on les anticipe — et ne se corrigent plus du tout sous la pression d’un closing.

La sécurité élémentaire

Pas la sécurité « niveau banque ». La sécurité élémentaire : secrets versionnés en clair dans Git, absence de chiffrement des mots de passe au repos, droits d’accès AWS partagés via un compte root unique, aucune politique de sauvegarde testée. Un audit trouve ces failles en une demi-journée, et chacune transforme la conversation. Le message implicite envoyé à l’investisseur n’est pas « ils ont une faille » — c’est « ils n’ont pas la culture d’ingénierie qu’on attend d’une équipe qu’on va financer à huit chiffres ».

La conformité RGPD réelle, pas déclarative

En contexte francophone, c’est le point le plus sous-estimé par les fondateurs tech. Avoir une politique de confidentialité sur son site ne suffit pas. L’auditeur veut un registre des traitements, savoir où les données personnelles transitent, si vos sous-traitants (Stripe, un outil d’emailing, un hébergeur hors UE) sont couverts par des clauses contractuelles, et si vous savez répondre techniquement à une demande d’effacement. Une startup B2B SaaS qui stocke des données clients européennes sur une infra US sans cadre de transfert valide ouvre une exposition que le fonds devra provisionner. Ce n’est pas anecdotique : c’est un sujet de term sheet.

La dette technique structurante

Toute la dette technique ne se vaut pas, et un bon auditeur le sait. Un code un peu sale mais isolé ne pèse rien. Ce qui inquiète, c’est la dette structurante : un schéma de base de données qui interdit le multi-tenant alors que votre roadmap commerciale promet du grand compte, un couplage si fort qu’aucune équipe ne peut travailler en parallèle, une absence totale de tests automatisés sur les flux critiques de paiement. Cette dette-là n’est pas un détail d’ingénierie — elle plafonne votre vitesse d’exécution future, donc directement la thèse de croissance que vous vendez.

Le bus factor de un

Si une seule personne détient les clés du royaume — l’architecture, les accès, l’historique des décisions — vous présentez un risque que beaucoup de fonds refusent de prendre. Le « bus factor de un » n’est pas un problème de compétence, c’est un problème de résilience organisationnelle. Et il se règle moins par de la documentation parfaite que par un vrai partage de connaissance dans l’équipe.

Pourquoi vous avez ignoré tout ça (et pourquoi c’était logique)

Il faut être honnête : au pre-seed et au seed, négliger ces sujets est souvent la bonne décision. Vous cherchiez le product-market fit. Chaque heure passée à durcir la sécurité ou à formaliser un registre RGPD était une heure non consacrée à valider que quelqu’un voulait acheter votre produit. Un fondateur qui passe son seed à construire une infrastructure « investor-ready » pour un produit que personne n’utilise se trompe de combat — c’est le pattern classique de la startup qui scale son infra avant d’avoir validé son ICP.

Le piège n’est pas d’avoir contracté cette dette. C’est de ne pas avoir gardé une carte des emprunts. La différence entre une DD qui se passe bien et une DD qui fait chuter la valorisation tient rarement à l’absence totale de dette — elle tient à la capacité du fondateur à dire : « Voici nos trois faiblesses connues, voici pourquoi nous les avons assumées, et voici le plan chiffré pour les traiter avec votre argent. » Un risque nommé et budgété rassure. Un risque découvert par l’auditeur effraie.

Ce qu’il faut vraiment faire, selon votre stade

Si vous êtes encore au seed, la bonne nouvelle est que presque tout se prépare en différé, à condition de poser trois garde-fous peu coûteux. Sortez vos secrets du code dès maintenant — un gestionnaire de secrets managé coûte quelques euros et vous évite la faille la plus embarrassante. Tenez un document vivant, même rudimentaire, qui liste les données personnelles que vous collectez et où elles vont : ce sera votre registre RGPD embryonnaire. Et faites en sorte qu’au moins deux personnes comprennent l’architecture, même si l’une code peu. Ces trois gestes ne ralentissent pas votre recherche de PMF et désamorcent 70 % de ce qui plombe une DD.

Si une série A est à six ou douze mois, le travail devient plus sérieux mais reste largement faisable. Commandez un pré-audit interne — soit par un consultant externe, soit par un membre senior de l’équipe avec le mandat explicite de chercher les problèmes plutôt que de les masquer. L’objectif n’est pas d’avoir une stack parfaite ; c’est d’arriver en DD avec votre propre rapport, vos faiblesses déjà identifiées et un plan de remédiation chiffré. Vous reprenez ainsi le contrôle du récit. Mettez en place une couverture de tests sur vos seuls flux critiques — paiement, authentification, données sensibles — pas partout, juste là où une régression coûte cher. Et formalisez votre conformité RGPD pour de vrai, surtout si vous adressez du grand compte qui l’exigera de toute façon dans ses propres clauses.

Si vous êtes en plein closing et que la DD a commencé, le mot d’ordre est la transparence proactive. Tout ce que l’auditeur découvre seul pèse trois fois plus lourd que ce que vous révélez vous-même. Devancez-le.

La dette technique est une dette financière déguisée

Le fil conducteur de tout cela mérite d’être explicité : chaque raccourci technique pris au seed est un emprunt dont la série A est l’échéance. Vous ne le voyez pas passer dans votre comptabilité, mais il apparaît noir sur blanc dans le rapport de DD, converti en points de valorisation perdus ou en clauses contraignantes. Un choix d’architecture n’est jamais purement technique : il fixe le plafond de votre vitesse future et le prix que des investisseurs accepteront de payer pour y avoir accès.

La vraie question n’est donc pas « notre code est-il propre ? » — il ne le sera jamais complètement, et ce n’est pas l’objectif. La question est : savons-nous précisément où sont nos dettes, pourquoi nous les avons contractées, et combien coûtera leur remboursement ? Une équipe qui répond à ça avec lucidité ne traverse pas la DD, elle s’en sert pour démontrer sa maturité.

Avant votre prochaine levée, posez-vous celle-ci : si un auditeur ouvrait votre dépôt demain matin, quelle serait la première chose que vous préféreriez qu’il ne voie pas ? C’est exactement par là qu’il faut commencer.