La due diligence technique à laquelle personne ne se prépare

Pendant mon passage comme CTO chez OneRagtime, j'ai mené des due diligences techniques sur les startups du deal flow. Le fonds passait au crible plus de 4 000 deals par an, et pour ceux qui passaient les premiers filtres, quelqu'un devait regarder sous le capot. Ce quelqu'un, c'était généralement moi.

Après avoir audité des dizaines d'entreprises, des schémas sont apparus. Les problèmes techniques qui tuaient les deals étaient rarement ceux auxquels les fondateurs s'attendaient. Et les choses qui impressionnaient les investisseurs étaient souvent les parties les plus banales de la stack.

Voici ce que j'ai appris.

Ce que les investisseurs regardent vraiment

Les investisseurs se fichent de ton choix de framework. Ils se fichent de savoir si tu utilises React ou Vue, Python ou Node, AWS ou GCP. Ce sont des détails d'implémentation. Ce qui les intéresse, c'est de savoir si ta fondation technique peut supporter le business que tu essaies de construire.

Les trois questions qui guident chaque due diligence technique sont simples. Est-ce que cette équipe peut livrer assez vite pour atteindre ses milestones ? Est-ce que la technologie va scaler avec le business ? Y a-t-il des risques cachés qui pourraient exploser après l'investissement ?

Tout le reste, les outils spécifiques, les patterns d'architecture, le style de code, est évalué à travers le prisme de ces trois questions.

Les signaux d'alarme qui tuent les deals

Pas de tests, pas de CI/CD. C'est le signal d'alarme le plus courant, et c'est presque toujours rédhibitoire. Si une startup n'a pas de tests automatisés et pas de pipeline d'intégration continue, ça me dit deux choses : ils ne peuvent pas livrer en confiance, et ils accumulent du risque à chaque déploiement. J'ai vu des startups avec du code magnifique mais zéro test. Peu importe à quel point ton code est propre si tu ne peux pas vérifier qu'il fonctionne après chaque changement.

Point de défaillance unique dans l'équipe. Si une personne a écrit 90 % de la codebase et que cette personne est le fondateur, que se passe-t-il quand il faut recruter ? Que se passe-t-il quand cette personne tombe malade ? Je demande toujours : "Si votre lead developer partait demain, combien de temps avant que l'équipe puisse livrer une fonctionnalité de manière autonome ?" La réponse me dit tout sur la distribution des connaissances et la documentation.

Pas de séparation d'environnements. Les startups qui déploient directement en production sans environnement de staging jouent avec le feu. J'ai vu des équipes qui testent en production parce que "c'est plus rapide." C'est plus rapide jusqu'au jour où ça ne l'est plus. Un mauvais déploiement sur une base de données de production et tu expliques une perte de données à tes utilisateurs.

La conversation "rewrite". Quand des fondateurs me disent qu'ils doivent réécrire leur codebase entière, je deviens nerveux. Parfois un rewrite est vraiment nécessaire. Mais le plus souvent, ça signifie que l'équipe a pris de mauvaises décisions architecturales tôt et ne les a jamais corrigées de façon incrémentale. Une équipe incapable de refactoriser de manière incrémentale est une équipe qui fera face au même problème après le rewrite.

Le sur-engineering. Celui-ci surprend les gens. J'ai tué des deals parce qu'une startup de cinq personnes avait une architecture microservices avec douze services, un cluster Kubernetes et une message queue, le tout pour servir quelques centaines d'utilisateurs. Ça me dit que l'équipe optimise pour l'élégance technique plutôt que l'impact business. Ça signifie aussi que leurs coûts d'infrastructure sont probablement dix fois ce qu'ils devraient être.

Ce qui impressionne les investisseurs

Des pipelines de déploiement propres. Une équipe capable de déployer en production plusieurs fois par jour en toute confiance est une équipe qui peut itérer vite. Chez OneRagtime, les startups qui m'ont le plus impressionné avaient des pipelines CI/CD simples et fiables. Pas complexes. Juste des pipelines qui fonctionnaient à chaque fois.

Du monitoring et des alertes. Quand je demande à un fondateur "comment savez-vous quand quelque chose casse ?" et qu'il me montre un dashboard avec de vraies métriques et des seuils d'alerte, je sais qu'ils prennent la fiabilité au sérieux. La plupart des startups en early-stage n'ont aucun monitoring. Elles découvrent les pannes quand les utilisateurs se plaignent.

La documentation des décisions. Pas la documentation du code, même si ça aide. Je parle de traces expliquant pourquoi l'équipe a fait les choix qu'elle a faits. Des ADR (Architecture Decision Records) ou même un simple document disant "on a choisi PostgreSQL parce que X, on reconsidérera quand Y" me montre une équipe qui réfléchit délibérément à sa direction technique.

La qualité du modèle de données. Le schéma de base de données me dit plus sur la maturité technique d'une startup que n'importe quel autre artefact. Des structures de tables propres, un indexage correct, des relations claires entre les entités, et pas de problème de normalisation évident. Quand je vois un modèle de données bien conçu dans une startup early-stage, je sais que le lead technique comprend ce qui compte.

L'honnêteté sur la dette technique. Chaque startup a de la dette technique. Celles qui m'impressionnent sont celles qui peuvent la montrer et expliquer le compromis. "On a pris ce raccourci parce qu'on devait livrer avant le Q3. Voici notre plan pour y remédier." C'est mille fois mieux que "notre code est parfait" ou un fondateur qui ne sait pas où se trouve la dette.

Les patterns dont personne ne parle

Certains patterns ne deviennent visibles qu'après avoir vu suffisamment d'entreprises.

La vélocité de l'équipe compte plus que la qualité du code. Une équipe qui livre des fonctionnalités chaque semaine avec du code brouillon surpassera une équipe qui livre chaque mois avec du code propre. La qualité du code compte, mais uniquement dans la mesure où elle affecte la capacité de l'équipe à continuer de livrer. J'ai investi dans des startups avec des codebases moches qui avançaient vite et généraient du revenu. J'ai passé mon tour sur des startups avec du beau code qui étaient bloquées en paralysie d'analyse.

La profondeur technique du fondateur fixe le plafond. Même dans les startups où le fondateur est "non-technique", les plus réussies ont un cofondateur ou un premier recrutement qui comprend vraiment le design de systèmes. Quand j'audite une startup et que le lead technique ne peut pas expliquer clairement sa propre architecture, c'est un signal de problème qui ne fera qu'empirer avec la croissance de l'équipe.

Les coûts d'infrastructure révèlent les priorités. Je demande toujours à voir la facture cloud. Pas parce que le montant exact m'intéresse, mais parce que ça me montre où l'équipe dépense. Une startup qui dépense des milliers par mois en infrastructure tout en servant des centaines d'utilisateurs a un problème de discipline des coûts. Une startup qui tourne léger avec une allocation intelligente des ressources me montre qu'ils comprennent que le cash est fini.

Comment se préparer

Si tu es fondateur et que tu prépares une due diligence technique, voici ce que je ferais.

D'abord, assure-toi que tu peux déployer en confiance. Mets en place du CI/CD si ce n'est pas encore fait. Écris des tests pour tes chemins critiques. Ce n'est pas optionnel. C'est l'attente de base.

Ensuite, connais ton architecture. Sois capable de la dessiner sur un tableau blanc et d'expliquer pourquoi chaque composant existe. Connais les compromis que tu as faits et ceux que tu ferais différemment aujourd'hui.

Troisièmement, prépare tes métriques. Combien de déploiements par semaine ? Quel est ton uptime ? Combien de temps faut-il pour onboarder un nouveau développeur ? Ces chiffres racontent l'histoire de ta culture engineering mieux que n'importe quel slide deck.

Quatrièmement, sois honnête sur ta dette. Chaque auditeur sait que tu en as. Essayer de la cacher est pire que de l'avoir. Montre-moi que tu sais où elle se trouve et que tu as un plan.

La vue d'ensemble

La due diligence technique ne se résume pas à trouver des problèmes. Il s'agit de comprendre si une équipe a la culture engineering pour réussir. Les meilleures startups que j'ai auditées n'étaient pas celles avec la technologie la plus sophistiquée. C'étaient celles où l'équipe livrait de manière constante, communiquait clairement sur ses compromis et construisait des systèmes adaptés aux vrais besoins de leur business.

C'est ce que je cherche. Et c'est ce que j'essaie de construire dans chaque équipe que je dirige.