TechMind
Comment Serena et TechMind ont confirmé leur conviction d'investissement en 3 semaines
Contexte
TechMind est un fonds d'investissement spécialisé dans les startups tech, avec plus de 50 millions d'euros investis depuis 2018 et un portefeuille qui compte Spendesk, Algolia, Aircall, Payfit, ou encore Yuka. En 2023, TechMind était en processus d'investissement sur une startup en Série A spécialisée dans le traitement de données avec une forte dimension data science, dont le produit s'adresse à des clients internationaux. Serena était également impliqué dans l'opération en tant que co-investisseur.
La due diligence juridique et financière était avancée. Il restait à vérifier que ce que la startup décrivait de sa tech correspondait à ce qui existait réellement. Avec une équipe de 4 personnes côté technique, dont des stagiaires, et un produit vendu à l'international, plusieurs questions se posaient : l'architecture était-elle réellement scalable, ou tenait-elle sur quelques personnes clés ? Le produit était-il réplicable à d'autres clients, ou avait-il été construit sur mesure pour en gagner un premier ? TechMind a mandaté Hones pour répondre à ces questions avant le closing.
Défis
Défi #1 — Vérifier que l'organisation pouvait absorber la croissance sans se fragiliser
Une équipe de 4 personnes en Série A, c'est une organisation où chaque départ ou indisponibilité a un impact immédiat. La question n'était pas seulement de savoir si l'équipe était compétente aujourd'hui, mais si elle était structurée pour intégrer de nouveaux profils sans dysfonctionner. La présence de stagiaires soulevait aussi un point précis : leur travail était-il documenté pour être repris, ou risquait-il de repartir avec eux ?
L'analyse de l'organisation a mis en évidence les dépendances à des personnes clés et évalué dans quelle mesure la startup avait anticipé ses prochains recrutements. Les rôles futurs nécessaires étaient identifiés, le travail des stagiaires était documenté.
Défi #2 — Évaluer si l'architecture data était scalable ou un POC amélioré
Une startup data science en Série A a souvent construit son produit pour convaincre ses premiers clients. Ce qui fonctionne à petite échelle, avec une équipe qui connaît les contours du système, ne tient pas nécessairement face à une multiplication des clients et des volumes. La question centrale : l'architecture était-elle conçue pour être répliquée, ou avait-elle été construite en fonction d'un seul cas d'usage ?
L'analyse de l'architecture a mis en évidence une dépendance forte à un fournisseur technologique tiers, identifiée comme point de vigilance à surveiller. Sur la réplicabilité, le diagnostic était plus rassurant : le produit n'avait pas été construit sur mesure pour un client unique.
Défi #3 — Auditer le passage entre data science et code de production
Les équipes data science travaillent typiquement sur des notebooks d'exploration, pas sur du code destiné à être maintenu en production. Le passage de relais entre ce que produisent les data scientists et ce que les développeurs mettent en ligne est un point de fragilité fréquent, rarement visible de l'extérieur. La qualité de ce qu'on déploie n'est pas la même chose que la qualité de ce qu'on expérimente.
Hones a examiné ce passage de relais spécifiquement : robustesse du code mis en production, processus entre les deux équipes, niveau de documentation. Le constat était satisfaisant, avec une organisation adaptée à la taille de l'équipe et une bonne conscience de ses propres limites.
Défi #4 — Vérifier la cohérence entre le discours en entretien et la réalité opérationnelle
Une due diligence tech n'est pas qu'une revue de code. C'est aussi une lecture de la façon dont une équipe parle de son propre travail. Est-ce qu'elle connaît ses points faibles ? Est-ce qu'elle a anticipé les évolutions nécessaires ? Est-ce qu'elle vend une vision raisonnable ou survend des capacités qu'elle n'a pas encore ?
Malgré un accès limité au code source (propriété intellectuelle sensible en contexte de due diligence), les entretiens avec les différents membres de l'équipe et l'analyse de la documentation ont permis de confronter le discours à la réalité. La concordance était bonne : l'équipe était consciente de ses limites et ne cherchait pas à les dissimuler.
Résultats
- TechMind et Serena ont investi au terme de la due diligence, avec une conviction renforcée plutôt qu'érodée par l'analyse technique.
- Les points de vigilance identifiés : dépendance à un fournisseur tiers, concentration sur quelques profils clés, ont été documentés et transmis aux deux fonds pour un suivi post-investissement.
- La start-up a bénéficié d'un état des lieux formalisé de ses forces et de ses chantiers prioritaires, utile pour piloter la période de croissance qui s'ouvrait.
- La startup a réalisé une nouvelle levée de fonds depuis, et une seconde due diligence Hones a été réalisée ultérieurement, ce qui indique une trajectoire solide depuis l'investissement initial.
Ce qu'on a appris
Sur les startups data science en early stage, l'enjeu technique le plus délicat n'est pas la qualité du code en soi. C'est l'interface entre la recherche et la production. Les data scientists sont recrutés pour explorer et modéliser, pas pour écrire du code maintenable. Quand cette distinction n'est pas gérée explicitement, avec des processus clairs de passage en production, des standards de documentation, une séparation des responsabilités, ce que l'investisseur achète comme actif tech est en réalité beaucoup plus fragile qu'il n'y paraît.
Le deuxième enseignement de cette mission concerne la réplicabilité du produit. Un premier client ne prouve pas qu'un produit est scalable. Il prouve qu'une équipe a su livrer une fois, dans des conditions qu'elle maîtrisait. La question à poser en due diligence n'est pas "est-ce que ça marche ?" mais "combien coûte le deuxième client ?"
