00:00:00 Introduction aux audits techniques de startups
00:01:42 Comment les VCs ont conduit Joannes vers les audits techniques
00:03:24 Les audits techniques comme source de revenus
00:05:08 Évaluation des logiciels dans les startups
00:06:36 L’expérience de Joannes en machine learning
00:08:50 Les aspects clés d’un audit technique
00:10:02 Les compromis entre sécurité et correction
00:11:46 Rédiger efficacement des rapports pour les investisseurs
00:14:57 Évaluer les startups au-delà des checklists
00:17:04 Adapter les audits au contexte commercial
00:20:24 Interview des CTO et revue de code en direct
00:24:12 Évaluer la familiarité des développeurs et leur leadership
00:28:22 Évaluer la compétence des développeurs
00:30:49 Signaux d’alerte dans la qualité du code
00:33:47 Aperçus tirés de l’historique des commits
00:37:03 La durabilité des coûts de cloud computing
00:42:14 Les LLMs perturbent les startups de NLP
00:46:29 Trouver des niches logicielles lucratives
00:50:32 Les risques de la dette technique
00:55:34 Surinvestir dans la scalabilité
00:59:59 Une écriture claire témoigne d’une bonne ingénierie
01:04:08 Pourquoi les audits techniques sont rares dans les investissements
01:07:12 Remarques de clôture
Résumé
Dans un épisode récent de LokadTV, Conor Doherty a interviewé Joannes Vermorel, PDG de Lokad, au sujet de son expérience de dix ans à réaliser des audits techniques de startups. Les “lightning tech audits” de Vermorel offrent aux venture capitalists des évaluations expertes des stacks technologiques, se démarquant des méthodes traditionnelles en se concentrant sur des évaluations dynamiques et spécifiques au contexte. Son processus implique des évaluations intensives sur une journée, incluant des entretiens avec les CTO et les équipes d’ingénierie afin d’évaluer la qualité du code et la fonctionnalité des équipes. Vermorel souligne l’importance de la passion, d’une documentation claire et d’une utilisation judicieuse des ressources dans le développement technologique. Ses constats révèlent des lacunes significatives dans l’industrie et mettent en lumière les meilleures pratiques pour les investisseurs et les entrepreneurs tech.
Résumé détaillé
Dans un épisode récent de LokadTV, Conor Doherty, Directeur de la Communication chez Lokad, s’est assis avec Joannes Vermorel, PDG et fondateur de Lokad, pour aborder l’une des activités moins connues mais très impactantes de Joannes : la réalisation d’audits techniques de startups. Au cours de la dernière décennie, Joannes a effectué ces audits, fournissant aux venture capitalists des avis d’experts sur les stacks technologiques des investissements potentiels. Cette pratique, que Joannes appelle les “lightning tech audits”, lui a procuré un point de vue unique sur les meilleures et les pires pratiques au sein de l’industrie tech.
Le parcours de Joannes dans les audits techniques a débuté dans les premières années de Lokad, alors qu’il envisageait de faire appel à des venture capitalists. Bien qu’il ait finalement décidé de ne pas accepter d’investissements formels, ses interactions avec les investisseurs l’ont conduit à proposer son expertise dans l’évaluation des aspects technologiques d’autres startups. Ce changement lui a permis de transformer ce qui aurait pu être des réunions chronophages en opportunités commerciales précieuses, en offrant ses services aux venture capitalists ayant besoin d’un avis expert sur les stacks technologiques des entreprises envisagées pour un investissement.
Le cœur du processus d’audit de Joannes est une évaluation intensive d’une journée, qui diverge significativement des méthodes d’audit traditionnelles. Contrairement à l’approche standard, qui repose fortement sur des checklists, la méthode de Joannes est dynamique et adaptée au contexte spécifique de chaque startup. Il commence par un entretien de 20 minutes avec le CTO afin de comprendre le paysage technologique de l’entreprise, puis passe le reste de la journée à mener des entretiens individuels avec l’équipe d’ingénierie. Cette approche pratique lui permet d’évaluer non seulement la qualité du code, mais aussi la fluidité et la cohérence de l’équipe dans l’utilisation de leur propre technologie.
Joannes souligne que son objectif n’est pas de devenir un expert de la technologie de l’entreprise, mais d’évaluer si l’équipe est fonctionnelle et si la trajectoire technologique est saine. Il recherche des motifs dans la base de code, l’historique des commits et la qualité de la documentation. Par exemple, il peut rapidement jauger la qualité de la base de code en observant la cohérence des styles de codage et la clarté des messages de commit. Il évalue également si l’équipe fait un usage judicieux de ses ressources limitées, un facteur critique pour les startups.
L’un des constats les plus marquants que Joannes a partagés est la fréquence à laquelle les entreprises technologiques peuvent traverser plusieurs cycles d’investissements sans que personne n’ait examiné sérieusement leur technologie. Il trouve étonnant que, même lors des cycles d’investissement ultérieurs, le stack technologique reste souvent incontesté. Ce manque de diligence peut conduire à des lacunes significatives, comme ce fut le cas célèbre de Theranos.
Joannes a également évoqué l’importance de la passion et du soin dans le développement technologique. Il estime qu’un manque de soin peut être fatal pour les entreprises tech. Lorsque le CTO et l’équipe d’ingénierie sont véritablement passionnés par leur technologie, cela se reflète dans la qualité et la cohérence de leur travail. Inversement, lorsque les entreprises externalisent leur développement à des freelances ou manquent d’un engagement profond envers leur technologie, les résultats sont souvent désastreux.
En ce qui concerne les meilleures pratiques, Joannes a souligné l’importance d’une écriture claire et d’une documentation précise. Qu’il s’agisse de commentaires dans le code ou de l’articulation d’énoncés de problèmes dans les tickets, la clarté et la concision sont des indicateurs d’une équipe bien fonctionnante. Il apprécie également l’utilisation de technologies inhabituelles mais bien adaptées, qui peuvent témoigner d’une compréhension approfondie du paysage technologique et d’un engagement à trouver les meilleures solutions.
L’approche de Joannes en matière d’audits techniques représente une rupture rafraîchissante avec la norme, en se concentrant sur les réalités pratiques et les besoins spécifiques de chaque startup. Ses constats offrent des leçons précieuses pour les investisseurs et les entrepreneurs tech, soulignant l’importance de la passion, de la clarté et d’une approche personnalisée du développement technologique. Alors que l’industrie tech continue d’évoluer, la méthode des lightning tech audits de Joannes fournit un cadre solide pour évaluer le véritable potentiel des innovations technologiques.
Transcription complète
Conor Doherty: Bon retour sur LokadTV. Aujourd’hui, je serai en studio avec Joannes Vermorel, fondateur et PDG de Lokad. Nous allons discuter de l’une de ses missions annexes uniques : réaliser des audits techniques de startups. Peu de gens réalisent qu’au cours de la dernière décennie, Joannes a évalué des entreprises de logiciels, examinant tout, du code à l’infrastructure en passant par le personnel et même le leadership. Lui et moi aborderons certaines des meilleures pratiques ainsi que ce qu’il a appris au fil du temps. Comme toujours, si vous aimez ce que vous entendez et que vous appréciez notre travail, abonnez-vous à la chaîne YouTube et suivez-nous sur LinkedIn. Sur ce, je vous présente la conversation d’aujourd’hui avec Joannes Vermorel. Joannes, bon retour. Comme je l’ai mentionné dans l’introduction, nous sommes ici pour parler non pas nécessairement de notre sujet habituel mais de quelque chose qui, je pense, revêt toujours un intérêt significatif. Vous réalisez beaucoup d’audits techniques, n’est-ce pas ?
Joannes Vermorel: Oui, et cela fait plus d’une décennie, probablement presque 14 ans environ.
Conor Doherty: Et comment cela a-t-il exactement débuté ? Parce que, encore une fois, tous ceux qui regardent LokadTV — que ce soit la septième ou peut-être la huitième année, comme Max hors caméra peut le confirmer — sont habitués à vous entendre parler de supply chain et de toute la tech qui y est impliquée. Mais c’est probablement la première fois que quelqu’un entend parler de cela, et pourtant vous venez de dire que vous le faites depuis 10 ans. Donc, en ce qui concerne les missions annexes, c’était une approche subtile. Comment cela a-t-il débuté exactement ?
Joannes Vermorel: Dans les premières années de Lokad, j’envisageais de prendre des investissements, vous savez, d’inviter des venture capitalists. Il s’est avéré que je n’ai jamais fait entrer d’investisseurs formels dans l’entreprise, mais dans les premières années de Lokad, j’ai parlé avec un bon nombre d’entre eux. Au bout d’un certain temps, vous savez, on finit soit par envoyer un e-mail, soit ils vous en envoient un en disant : “Oh, prenons un café ou quelque chose comme ça.” Il faut du temps pour rencontrer des investisseurs afin de discuter de votre entreprise et de voir s’ils seraient intéressés à investir, et ainsi de suite. Cela prend du temps, et à un moment donné, je me suis dit : “D’accord, je passe tout ce temps à rencontrer ces investisseurs potentiels, et ce temps-là, je ne le consacre ni à construire ni à vendre.” Alors je me suis dit : “Et si je leur vendais quelque chose ?” En somme, traiter ces réunions avec des venture capitalists comme des réunions de vente. Il s’est avéré que j’ai mentionné à ces personnes que, si elles étaient intéressées — je n’étais pas vraiment pour eux un prospect brûlant puisque je ne cherchais pas désespérément de l’argent — je leur disais que Lokad n’était peut-être pas leur startup idéale parce que je ne cherchais pas désespérément de l’argent. Mais s’ils cherchaient quelqu’un pour forger un avis expert sur un autre investissement, je pouvais être la personne qu’il leur fallait. Ma spécialité n’était pas de regarder une autre startup et de juger si elle allait être rentable — c’est au-delà de mon expertise, c’est très difficile. Mais ce qui relevait de mon expertise, c’était d’avoir un avis éclairé sur leur stack technologique. Il s’est avéré que lorsqu’on est venture capitalist et qu’on investit dans des entreprises tech, une grande partie de la valorisation de beaucoup de ces entreprises repose sur la technologie qu’elles développent. La technologie est-elle réellement précieuse ? Vale-t-elle la valorisation pré-money que les fondateurs demandent ? Et donc, eh bien, j’ai commencé à réaliser ces audits techniques. J’en fais environ un, parfois deux par mois depuis, encore une fois, je pense que cela fait 12 ou 13 ans, donc cela fait un bon bout de temps. Et ainsi, j’ai audité de nombreuses entreprises, et le format de ces audits est très court. Au fait, vous demandiez comment je trouvais le temps de faire cela. Eh bien, j’ai toujours gardé ces audits sous la forme de lightning tech audits ; tout est réalisé en une journée.
Conor Doherty: Nous reviendrons certainement là-dessus, car cette approche a des implications. Nous aborderons en quoi votre méthode diffère de ce que la plupart des gens considéreraient comme le statu quo pour ce qui revient essentiellement à un service de consultation. Toutefois, simplement pour poser le cadre, puisque vous avez utilisé les termes “expert opinion” et “expertise”, n’hésitez pas à énumérer vos nombreux lauriers pour quiconque ne serait pas familier avec ce qui vous qualifie pour ce poste.
Joannes Vermorel: Je suis passionné par les technologies logicielles depuis longtemps. J’ai commencé à programmer à l’école primaire, j’ai passé la majeure partie du collège et du lycée à perfectionner mes compétences en programmation avec des choses de plus en plus sophistiquées, et j’ai toujours été extrêmement intéressé par tout ce qui touche aux logiciels. Au moment où j’ai commencé à réaliser ces audits, je n’avais pas encore 30 ans mais j’en approchais, et j’avais déjà près d’une décennie d’expérience professionnelle en logiciels grâce à mes propres projets, mais aussi à d’autres projets que j’avais réalisés à l’université et dans d’autres entreprises.
Conor Doherty: Vous avez également travaillé en Amérique pendant un certain temps chez AT&T Labs. C’était une époque où ils étaient vraiment des pionniers en machine learning. Ils ont commencé à se lancer dans le machine learning dès les années 90.
Joannes Vermorel: Oui, ils s’intéressaient au machine learning bien avant que l’intelligence artificielle ne devienne populaire et surmédiatisée. Il y avait des personnes qui travaillaient sur ce sujet, mais encore une fois, ce n’était qu’une partie de mon intérêt. Lorsque j’audite des entreprises, très souvent le machine learning ne représente qu’une infime portion des problèmes. Très souvent, il ne fait même pas partie du problème. Ces entreprises peuvent être de toutes sortes. On trouve des entreprises de logiciels, mais elles peuvent aussi être des sociétés de biotechnologie qui utilisent abondamment les logiciels, des sites de jeux d’argent en ligne, des applications de productivité B2B, ou encore des logiciels embarqués qui se retrouvent dans un appareil situé dans une salle d’opération d’un hôpital. Le logiciel intervient dans une gamme extrêmement large de situations, et les technologies utilisées par ces startups varient énormément d’une entreprise à l’autre, même si le cœur reste toujours le logiciel. C’est là que je pense que réside vraiment mon expertise.
Conor Doherty: Quand vous parlez de réaliser des audits techniques, je pense que les gens ont probablement une idée de ce que cela implique. Mais qu’est-ce qui entre exactement dans ce processus ? Sur quels aspects vous concentrez-vous ? Évaluez-vous uniquement les logiciels ? Évaluez-vous les personnes ? Qu’est-ce qui est exactement évalué ?
Joannes Vermorel: Le livrable, car nous devons commencer par ce qui est livré, est une note de synthèse que je rends à l’investisseur. Un capital-risqueur s’apprête à investir dans une startup. Ils disposent généralement d’une lettre d’intention déjà signée. Ils s’apprêtent à injecter entre 2 millions et 20 millions, parfois plus, de dollars ou d’euros dans une entreprise. Une grande partie de l’évaluation repose sur les technologies dans lesquelles ils investissent. Ils investissent dans une équipe qui a soi-disant déjà développé quelque chose. Je ne réalise pas ces audits pour le stade d’amorçage ; nous parlons ici de Series A, parfois de Series B. Nous parlons donc de personnes qui ont normalement, à ce stade, déjà développé quelque chose, ce qui justifie une évaluation plus élevée. La question est donc : cela vaut-il ce qu’ils demandent ? La valeur ne se résume pas uniquement à ce qu’ils possèdent, mais aussi aux dynamiques technologiques au sein de l’entreprise afin qu’elle puisse, si elle obtient l’argent de l’investisseur, atteindre les objectifs de sa feuille de route. Les gens investissent non seulement dans ce qu’est l’entreprise, mais surtout dans ce qu’elle deviendra demain. Je ne peux pas évaluer si leurs projections financières seront correctes. Mon expertise ne réside pas dans l’avenir, disons, des marchés de jeux de hasard. Je ne sais pas. Cela revient à d’autres de l’évaluer. Mais s’ils me montrent une application de jeux de hasard, nous devons vérifier qu’elle sera sécurisée car, dans le cas des jeux de hasard, par exemple, elle doit être extrêmement sécurisée. C’est le genre de question à laquelle je peux répondre. S’il s’agit d’un appareil qui sera utilisé lors d’une intervention chirurgicale, alors la justesse est absolument vitale. Littéralement, si l’appareil fonctionne mal, il peut potentiellement tuer un patient. Les défis sont très différents.
Conor Doherty: Pour revenir à l’exemple que vous avez donné, j’ai bien compris celui de la sécurité, et évidemment, avec votre veste, mais concernant l’équipement chirurgical, quelle est votre approche en termes d’évaluation de cette justesse ? Va-t-il accomplir de manière fiable ce qu’il est censé faire ?
Joannes Vermorel: Ce n’est pas un problème de sécurité car ces appareils seront isolés du réseau. Ils seront exploités dans un environnement déjà très sécurisé du point de vue IT — pas de connexion réseau, ce genre de choses. Mais la question est : comment faire en sorte qu’ils ne présentent pas de pannes, de bugs ou tout autre problème susceptible de compromettre littéralement leur bon fonctionnement ? De nombreuses machines sont aujourd’hui automatisées. Si elles actionnent une pompe qui injecte un fluide dans le patient, comment s’assurer qu’elles ne défaillent pas, qu’elles fassent exactement ce que vous attendez ? En fin de compte, ma démarche pour aborder le livrable consiste à me forger une opinion. Ce sera une note de synthèse que je restituerai à l’investisseur concernant mon opinion générale sur la valeur de cette entreprise, en fonction de ses propres critères. Et c’est vraiment ce qui compte. J’essaie de me faire une opinion sur ce que l’entreprise vaut en fonction de ce qu’elle cherche à accomplir. Si vous développez un jeu vidéo, la question est de savoir si vous concevez quelque chose de très addictif, très engageant, amusant, etc. Ce sont vos critères d’engagement. Si vous développez une biotech dotée d’une nouvelle technologie de diagnostic censée permettre de détecter une pathologie plus tôt et plus rapidement qu’une méthode alternative, est-ce que cela fonctionne ? Est-ce réel ? Disposez-vous de statistiques fiables ? Avez-vous mis en place tous les processus qui semblent indiquer que vos résultats empiriques sont exactement tels qu’ils devraient être ? Si nous avons une application de productivité, la question est, pour une application B2B, comment gérer le fait que vous avez des centaines, potentiellement des milliers, de fonctionnalités ou de micro-fonctionnalités ? C’est le problème des applications d’entreprise ; elles peuvent ressembler à un labyrinthe de fonctionnalités en raison du nombre de cas à traiter. Comment l’entreprise gère-t-elle toute cette complexité ? Sont-ils en train de se noyer dans leur propre complexité ou la maîtrisent-ils bien ? Est-ce bien organisé ? Selon le type de startup que j’audite, les critères d’engagement — quelle est la proposition de valeur, l’essence même de la valeur — varient énormément. Mon livrable consiste à me forger et exprimer une opinion que je rends à l’investisseur sur ce qui compte le plus. S’il y a quelque chose que je constate lors de cet audit qui compromet la livraison de cette valeur fondamentale, je le signale.
Conor Doherty: Encore, vous avez dit que vous faisiez cela depuis environ 10 ou 12 ans. En supposant un à deux audits par mois, on parle d’au moins plus de 100 audits réalisés. Alors, quelle serait la majeure partie ? Parce que vous avez indiqué, par exemple, que vous pourriez examiner une application de jeux de hasard, ou du matériel médical. Évidemment, ces secteurs sont très, très différents. Donc, la majeure partie de votre travail s’est effectuée dans… ou, quelle est l’ambiance typique lorsque vous auditez ?
Joannes Vermorel: Il s’agit essentiellement d’entreprises de logiciels. Ce sont des personnes qui développent du logiciel. Parfois, il y a un aspect physique, vous savez, cela peut concerner des personnes qui développent des logiciels pour un équipement. Parfois, il s’agit d’intégrer plus ou moins de logiciels tiers. Est-ce une application autonome ou est-elle intégrée à beaucoup d’autres systèmes ? Il existe de nombreuses situations. Je veux dire, évidemment, probablement les deux tiers de ce que j’ai réalisé concernent le B2B ou des équipements professionnels, et un tiers le B2C. Mais c’est tout ce que peut apporter une classification ; sinon, c’est extrêmement diversifié.
Conor Doherty: Eh bien, vous nous avez donné une vue d’ensemble efficace des livrables et de votre parcours. Mais en ce qui concerne les étapes majeures, comment vous forgez-vous une opinion et quelles sont les étapes pour parvenir à cette note de synthèse et à cette opinion ?
Joannes Vermorel: C’est là que mon approche diverge largement de ce que l’on considère généralement comme un processus d’audit. Pour résumer pour l’audience, un auditeur — je dirais que 99 % des personnes qui réalisent des audits, quelque soit leur nature — disposent de listes de contrôle. Ils ont de longues listes comportant plusieurs centaines de questions, et ils se rendent dans l’entreprise pour demander « Faites-vous ceci ou cela ? » Oui, non, oui, non, etc. L’auditeur parcourt simplement la liste comme un drone. Selon moi, ce processus est complètement absurde pour les audits technologiques, en particulier pour les startups.
The problem is that this list, whatever it is, is never going to challenge the startup on its own terms. It’s completely irrelevant to challenge, let’s say, a company doing gaming on whether they are super secure. If you do a video game, security is a secondary concern. In a startup, your resources are scarce. Does it make sense for most video games to invest in having a security officer and invest heavily in security features that complicate the life of the users? If you’re doing casual video games, for example, it doesn’t make any sense. Nobody cares about the fact that you’re playing Farmville.
The bottom line is that having checklists is a recipe to be a massive waste of time for the founders and a massive distraction for the investors themselves. They might say, “Oh, the startup is compliant with hundreds of irrelevant items,” and then you would say, “Oh, but they’re not compliant on these 100 items,” which are also completely irrelevant to the success of the company. My take is that they have a business case; they say they want to go in a certain direction business-wise. I let other people assess if there is money to be made. I don’t assess that. I mean, yes, I have my own opinion on whether it seems plausible, but I don’t challenge the size of the market. My take is that, okay, let’s assume there is a market and that if you execute this thing excellently, there will be people to serve, and those people will be willing to pay you.
Now the question is really, will you deliver on your premise? You are developing a technology that is supposed to do something. Will you deliver on what you’re actually promising?
Conor Doherty: Et vous êtes en position de fournir ce niveau d’analyse. Vous pouvez spéculer sur la technologie et…
Joannes Vermorel: Comparé à un auditeur, pour revenir à la liste de contrôle, mon point de vue est que, lorsque je commence la journée, pendant les 20 premières minutes, j’interviewe typiquement le CTO. L’idée est que, durant ces 20 minutes, je dois élaborer mentalement une série de questions pour orienter la discussion vers ce qui présente le plus d’intérêt. Après ces 20 minutes de présentation, généralement sous forme de conversation informelle, je poursuis le reste de la journée par une série d’entretiens, au cours desquels quelqu’un, assis devant un ordinateur, me montre leur codebase. Je réalise une série d’entretiens individuels durant lesquels nous regardons ensemble le même écran, et un employé de l’entreprise agit comme mon guide à travers leur codebase.
Conor Doherty: Donc, vous êtes Virgile.
Joannes Vermorel: Oui, ils me guident à travers leur codebase. Je ne demande pas une copie de celle-ci car cela pourrait engendrer énormément de problèmes et me rendre responsable en matière de propriété intellectuelle. L’idée est que je veuille examiner la codebase, et c’est ainsi que j’analyse la technologie. Mais les codebases peuvent être extrêmement volumineuses. Même une petite entreprise avec cinq ingénieurs logiciels travaillant pendant quelques années peut facilement compter 100 000 lignes de code ou plus. Si je devais naviguer seul dans cette codebase, 90 % de mon temps serait perdu à tâtonner. Ainsi, j’ai un ingénieur assis à côté de moi, je pose des questions, et il me montre le code. Nous passons en revue le code ensemble, évidemment sur un échantillon du code — nous ne pouvons pas examiner l’intégralité de la codebase.
Conor Doherty: Vu les enjeux financiers potentiels ici, pourquoi ne pas examiner cela simplement avec le CTO ?
Joannes Vermorel: D’abord, le CTO n’est pas nécessairement au fait de toutes les parties de la codebase. Si c’est une équipe de cinq personnes, y compris le CTO, alors probablement que le CTO maîtrise l’intégralité de la codebase. Si vous parlez d’une entreprise à un stade ultérieur avec 20 ingénieurs, il est fort probable que le CTO ne soit pas compétent sur chaque segment de la codebase. Mais, de manière plus générale, il m’est également très intéressant d’avoir d’autres personnes de l’entreprise assises à côté de moi, afin de voir à quel point ils maîtrisent la codebase. Sont-ils perdus dans leur propre technologie ? Lorsque je pose une question basique, par exemple « Comment accédez-vous à votre couche persistante ? » ou « Comment accédez-vous aux données que vous avez enregistrées ? » et que les gens n’ont aucune idée, ce n’est pas bon. Si je leur demande « Quelle est la dernière chose que vous avez réalisée ? » et qu’ils répondent « J’ai développé cette fonctionnalité » sans pouvoir clairement me montrer ce sur quoi ils travaillent actuellement, ce n’est pas bon.
Interviewer le CTO, c’est bien, mais je dois également évaluer si l’équipe est à la hauteur du CTO. Cela peut aller dans les deux sens. Parfois, le CTO est très compétent, mais le reste de l’équipe ne l’est pas autant. Parfois, c’est l’inverse. Parfois, le CTO est très faible, mais le reste de l’équipe est en réalité assez solide. Cela varie, et cela fera partie des opinions que je transmettrai à l’investisseur dans cette note de synthèse. J’ai aussi une opinion sur la capacité des contributeurs actuels de l’entreprise à relever les défis de la prochaine phase. Si l’investissement se concrétise, il arrive parfois qu’au démarrage, le budget de l’entreprise soit extrêmement limité et qu’elle opte pour des personnes qui ne sont pas très talentueuses sur le plan technologique. Cela se produit fréquemment lorsque le fondateur n’est pas un fondateur technique. Quand le fondateur est quelqu’un qui disposait d’une connaissance interne, qui sait qu’il existe un problème spécifique à résoudre, et que cette personne perçoit un besoin et une volonté de payer. Cela arrive très fréquemment sur les marchés B2B. Mais cette personne n’est pas technique, donc elle recrute le premier ingénieur logiciel qu’elle peut trouver. Il se peut qu’elle n’ait pas un gros budget, de sorte que son premier recrutement pourrait être quelqu’un dont le principal atout est d’être très bon marché.
Encore, ce n’est pas grave, ce n’est pas grave. Je veux dire, vous partez de zéro. Vous avez, disons, 20 000 €, que vous injectez dans l’entreprise. Pour vous, c’est déjà un investissement conséquent. Grâce à ces 20 000 €, vous parvenez à mobiliser, disons, un financement d’amorçage d’environ un demi-million. C’est bien. Vous pouvez constituer votre équipe, disons, de deux ingénieurs logiciels pour développer le produit. Puis vous souhaitez passer à l’étape suivante et obtenir le premier tour de financement, disons, de 3 millions d’euros. À ce stade, s’il s’agit d’un investissement de plusieurs millions, c’est le moment où vous disposez de l’argent nécessaire pour attirer de vrais talents en ingénierie logicielle. La question est donc : les acteurs que vous avez actuellement sont-ils prêts à relever le défi pour passer au niveau supérieur, à la prochaine étape de l’entreprise ? Ce n’est pas la seule question, mais c’est l’une des interrogations examinées.
Conor Doherty: Pour être clair, dans le cadre du mémorandum, le livrable, feriez-vous éventuellement des recommandations sur qui devrait rester et qui ne devrait pas rester ?
Joannes Vermorel: Oui, oui. Encore une fois, c’est tout ce qui pourrait aider ou compromettre la valeur technologique de l’entreprise, sa trajectoire technologique. Parfois, vous avez les mauvais joueurs. Je veux dire, vous aviez les joueurs dont vous aviez besoin pour remporter un championnat super local, mais si vous voulez jouer à l’échelle nationale ou même viser le championnat du monde, alors peut-être avez-vous besoin de joueurs différents. Apporter plus d’argent change la dynamique. Soudainement, vous pouvez potentiellement vous permettre d’embaucher des personnes bien plus expérimentées, bien plus talentueuses. Ça varie. Parfois, les gens sont très talentueux, mais pour une raison quelconque, la dynamique dans l’entreprise est vraiment mauvaise. Parfois, il peut y avoir deux CTO pour une raison quelconque. Cela est arrivé lors de certains audits. Vous vous retrouvez donc avec deux responsables technologiques, et ces deux personnes poursuivent des feuilles de route différentes. Alors mon message est : choisissez-en un. Vous ne pouvez pas rester complètement schizophrène ; vous devez choisir. Ce serait une décision commerciale car il s’agit de marchés différents que vous essayez de conquérir. Mais en fin de compte, c’est le genre de problème où un investisseur doit savoir s’il y a un problème avec la tech ou s’il y en aura un dans le futur. Parce que parfois il n’y a pas encore de problème, mais ajouter de l’argent, c’est comme mettre de l’essence sur le feu. Si vous avez quelque chose qui est légèrement dysfonctionnel, si vous commencez à verser quelques millions par-dessus, ce qui était un petit problème pourrait être amplifié de manière énorme par l’investissement lui-même. Cela peut aussi poser problème. Encore une fois, il n’y a pas de checklist pour moi, il n’y a pas de règles. C’est tout ce que je vois qui a du sens en termes de problèmes à résoudre ou de recommandations pour l’investisseur. Cela fait partie de mon champ d’intervention. L’idée est que je garde cela comme une mission d’une journée parce que je n’ai pas le temps d’en faire beaucoup plus. Mais aussi parce que les fondateurs eux-mêmes sont très occupés. Je pense qu’une partie du problème avec les audits classiques, c’est que ces choses sont une perte de temps. Cela prend des semaines, cela paralyse complètement l’entreprise, et il n’en ressort rien de bon.
Conor Doherty: Eh bien, sur ce point en fait, vous voulez dire que vous n’utilisez pas de checklist, vous visez à être sur place et repartir en moins d’une journée. Quand vous dites une journée, cela signifie une journée de travail. Donc, vous parlez d’un processus au lieu de plusieurs semaines, c’est-à-dire de plusieurs semaines de journées de 8 heures, vous parlez de peut-être 8 à 10 heures, taxis et vols exclus, sans utiliser de checklist, et ensuite de formuler des recommandations très conséquentes sur ce qui devrait être fait pour l’entreprise, des choses qui auront un impact sur les autres. Je dois vous demander, étant donné toutes ces contraintes, êtes-vous tout simplement si brillant, ou comment exactement arrivez-vous à prendre ces décisions en une seule journée sans checklist?
Joannes Vermorel: Oui, je veux dire, d’abord, la base de code. Si vous avez l’habitude de lire beaucoup de bases de code, ces choses deviennent extrêmement évidentes. En quelques minutes seulement à regarder la base de code, vous voyez si le code est bien écrit ou s’il est carrément nul. J’ai généralement une opinion en 5 minutes à parcourir cette base de code. Si vous êtes vraiment habitué à lire dans de nombreux langages de programmation et que vous avez vu de nombreuses bases de code, vous n’avez pas besoin d’heures pour vous forger une opinion sur le fait que c’est une ingénierie soignée et bien organisée qui a du sens, ou si c’est juste un chaos pur et incohérent. Par exemple, si je parcours une base de code et que je vois des styles de codage radicalement différents, je dis, “Ah, d’accord, donc nous avons différents contributeurs qui n’ont aucun accord commun sur la façon dont le code devrait être écrit.” C’est vraiment mauvais. Est-ce que je regarde l’historique des commits ? Cela me dit beaucoup de choses. Par exemple, si je vois que dans l’historique des commits, vous avez un commit pour une fonctionnalité puis deux douzaines de commits pour corriger des bugs causés par l’introduction de cette fonctionnalité, c’est super mauvais. Cela signifie que chaque fois que les gens introduisent quelque chose, ils passent ensuite beaucoup de temps à simplement corriger ce qu’ils viennent de casser. Vous voyez, rien qu’en ayant un aperçu rapide des quelque 200 derniers commits, vous pouvez voir s’il y a une tendance. Vous pouvez observer de nombreux schémas. Parfois, par exemple, vous avez l’historique des messages de commit. C’est l’évolution pour l’audience. Les commits sont la manière dont vous modifiez la base de code de façon incrémentale. Vous apportez des modifications et, de nos jours, vous utilisez généralement Git. Nous l’utilisons pour le web, et chez Lokad, nous l’utilisons comme tout le monde pour notre stack technologique. La question est, par exemple, quand vous voyez des modifications appliquées à la base de code, est-ce que ces changements ont du sens ? Par exemple, si vous avez des commits dont le titre est “more stuff”, littéralement, qu’est-ce que ce ramassis de merde ? Non, il ne s’agit pas seulement de modifications insignifiantes. Ensuite, par exemple, si vous avez un bug qui est corrigé, y a-t-il quelque chose qui est fait en parallèle pour s’assurer que le bug ne sera pas réintroduit la prochaine fois que vous touchez à la base de code ? Il existe de nombreuses façons de s’en assurer. En prenez-vous soin ? Quand vous regardez les contributions, les commits, est-ce que les gens font des revues de code ? Discutent-ils de la manière dont les choses devraient être conçues ? Encore une fois, la base de code racontera une histoire immense à la fois sur ce qu’est la technologie et sur son historique. Vous pouvez voir la trajectoire, comment elle s’est développée. Ensuite, vous pouvez zoomer sur les parties essentielles. Par exemple, si vous êtes une startup d’IA ou de machine learning, votre valeur fondamentale est censée être une sorte de recette numérique intelligente qui réalise quelque chose de très difficile ou autre. Comment faites-vous cela ? Est-ce juste un tour de passe-passe ou avez-vous une expertise approfondie ? Quelle barrière défensive avez-vous ? Avez-vous une véritable protection où reproduire ce que vous venez de faire sera difficile, ou est-ce juste un tour d’illusionniste où vous utilisez simplement une sorte de bibliothèque open source et bam, en réalité, rien n’est en production ? Vous venez juste de recycler quelque chose qui existe dans la communauté. Encore une fois, c’est une question très critique pour l’investisseur, car si les gens disent, “Oh, nous avons développé une technologie de machine learning unique,” si ce que vous faites consiste essentiellement à réutiliser un morceau d’open source, n’importe qui peut le faire. Donc oui, c’est cool, oui, ça fonctionne, mais l’investisseur doit-il valoriser votre entreprise de façon excessive simplement parce que vous avez quelque chose qui fonctionne ? Eh bien, pas vraiment, car si c’est open source, cela signifie que pratiquement n’importe qui peut le faire aussi. Donc, pas de véritable barrière défensive. Encore une fois, les éléments que j’examine dépendent vraiment des spécificités de l’entreprise.
Conor Doherty: Vous pouvez aussi, même en prenant simplement l’exemple et en y ajoutant une petite anecdote, si vous examinez le journal des commits dans Git ou Bitbucket – nous utilisons Bitbucket – en déduire pas mal de choses. Par exemple, même pour nous dans l’équipe marketing, chaque fois que nous mettons quelque chose sur le site web, vous insistez pour que le journal de commits soit très propre et bien organisé. Vous pouvez voir exactement ce qui s’est passé, qui l’a approuvé.
Joannes Vermorel: Exactement. Et aussi, parfois, ce sont simplement les interactions avec les gens. Je parle à quelqu’un, je pose une question au hasard : est-ce que cette personne est ultra-rapide pour me diriger directement vers le bon endroit dans le code ? Par exemple, “Oh, il y a cette fonctionnalité plutôt intéressante, pouvez-vous me montrer le code qui y est lié ?” Et puis, le gars répond, “Oh oui, pas de problème,” bam, directement dans l’implémentation. C’est très bien. Cette parfaite maîtrise de la base de code, de la manière dont les choses sont faites, c’est vraiment, vraiment appréciable. Ainsi, parfois, la facilité avec laquelle les gens naviguent dans la base de code m’en dit long. De plus, par exemple, lorsqu’ils introduisent des fonctionnalités, possèdent-ils des tickets bien rédigés pour les justifier ? Est-ce que les ingénieurs logiciels se débrouillent de manière désordonnée avec le code, ou disposent-ils d’un système bien organisé du type “D’accord, je veux faire cela, voici mon ticket qui décrit clairement pourquoi je veux le faire,” puis je discute des différentes manières de procéder, etc. Cela dépend, mais c’est typiquement l’importance des tickets. Ce serait généralement crucial pour les applications B2B, les applications de productivité, car vous avez une liste infinie de fonctionnalités toutes très spécifiques au domaine. Si vous développez une application d’entreprise, vous ne devriez vraiment pas vous perdre dans l’infinité de fonctionnalités que vous pourriez ajouter. Cela revêt donc une importance particulière selon le type d’entreprise. Ce serait un processus complètement différent. Mais ce que je dis, c’est qu’en ce qui concerne la manière de se forger une opinion en seulement quelques heures – si vous êtes assis à côté de quelqu’un qui interagit avec la base de code, vous pouvez voir énormément de détails. En prêtant attention aux schémas, à ce que font les gens, et oui, c’est de la reconnaissance de motifs. Il y a un nombre fini de domaines dans lesquels les gens peuvent être bons ou mauvais selon une certaine vocation.
Il y a un nombre fini de choses dans lesquelles les gens peuvent être bons ou mauvais compte tenu d’une certaine vocation.
Conor Doherty: Oui, et vous vérifiez aussi la cohérence, vous savez. Est-ce que les gens racontent la même histoire en termes de technologie ? Par exemple, je demande, “Que pensez-vous que fait ce composant ?” Et si j’obtiens plusieurs personnes qui me donnent des explications complètement différentes, je dis, “D’accord, il est clair qu’au sein de cette équipe, il n’est pas évident que chacun comprenne vraiment ce qui se passe.”
Joannes Vermorel: Je n’ai pas besoin de la vérité pour reconnaître que les choses sont incohérentes. Encore une fois, mon but n’est pas de devenir un expert de ce qu’ils font. Mon objectif est simplement d’évaluer si l’équipe est fonctionnelle, si la trajectoire en termes de développement de la technologie est saine. Parfois, il s’agit également de vérifier, par exemple, que les ressources de cloud computing sont bien maîtrisées. Parfois, vous avez des entreprises qui gèrent mal leurs ressources de cloud computing. Le cloud est fantastique, avec un paiement à l’usage, ce qui signifie que le ciel est la limite. Vous pouvez déployer des tonnes de machines virtuelles, des tonnes de stockage, des tonnes de tout. Et parfois, vous savez, certaines entreprises deviennent un peu folles à ce sujet et finissent avec une trajectoire où elles dépensent beaucoup trop en ressources de cloud computing par rapport à ce qu’elles devraient.
Conor Doherty: Cela dépend encore une fois de ce qu’ils font. Combien devriez-vous payer pour les ressources de cloud computing ? Eh bien, cela dépend vraiment de ce que vous essayez d’accomplir. Il n’existe donc pas de règle claire, mais une partie de l’expérience consiste à évaluer quelle est la charge de travail que vous tentez de réaliser sur le cloud et si cela a du sens de payer autant. Est-ce un exploit, bravo, votre logiciel est extrêmement performant, ou est-ce super mauvais et vous êtes simplement en train de brûler de l’argent ? Se retrouver avec des tonnes d’argent en trop à brûler n’est sûrement pas la bonne stratégie. Vous devriez probablement résoudre ces problèmes avant d’obtenir quelques millions supplémentaires.
Joannes Vermorel: Si vous manquez d’argent, vous ne pouvez pas vous discipliner pour ne pas brûler d’argent à cause de dépenses inconsidérées en ressources computationnelles. Les chances que vous deveniez raisonnable une fois que vous aurez beaucoup plus d’argent sont extrêmement faibles.
Conor Doherty: Sur ce point, nous avons en fait une autre vidéo sur le sujet des ressources computationnelles, alors consultez la playlist pour cela. Mais sur le sujet de l’argent, quand vous parlez de finances, je sais que lorsque nous évoquons la supply chain, vous parlez de l’impact financier net de chaque choix que vous allez faire. Adoptez-vous la même approche lors de l’évaluation d’une entreprise tech ? Regardez-vous ce qui représente l’orchestration la plus bénéfique financièrement pour l’entreprise technologique ou simplement ce qu’il y a de meilleur en termes de tech, indépendamment du prix ?
Joannes Vermorel: Non, non, non. Chaque startup dispose de ressources limitées. L’idée – et c’est encore le problème avec les checklists – c’est que les checklists adoptent une perspective absolue. Elles disent que vous devez faire ceci, ceci, ceci et ceci. Ma perspective est toujours complètement relative à la maturité de l’entreprise.
Conor Doherty: Oui, exactement, selon leurs propres termes.
Joannes Vermorel: Vous ne voulez pas, par exemple, qu’il soit totalement insensé pour une petite entreprise de viser une certification ISO. C’est une perte totale de ressources, sauf dans un marché hyper-réglementé où vous ne pouvez pas survivre sans cette certification. Ce que j’examine, c’est à quel point vous êtes capable d’utiliser vos ressources limitées pour en tirer le maximum. Je pars du principe que votre orientation est bonne, qu’en fin de compte, si vous réussissez, vous ferez de l’argent. Mais malgré tout, si je prends vos orientations commerciales pour acquises, je me dis, “D’accord, admettons que si ce projet aboutit, alors vous serez compétitif sur ce marché et il y aura de l’argent à gagner.” Je pars de là. Maintenant, chaque dollar ou euro dépensé pour devenir ce leader numéro un sur ce marché, est-il dépensé judicieusement ?
Conor Doherty: Absolument. Cela peut concerner, par exemple, savoir si vous disposez des bons talents ? Parfois, ils dépensent trop peu. Il arrive que l’entreprise atteigne un certain succès et qu’elle ne se sépare pas de personnes qui avaient été embauchées à l’origine simplement parce qu’elles étaient extrêmement bon marché. Cela se produit aussi assez fréquemment dans les startups tech.
Joannes Vermorel: Surtout lorsque le fondateur n’est pas un fondateur tech, mais un fondateur commercial, puis il y a le CTO qui fut initialement le premier ingénieur logiciel embauché par l’entreprise. Cela arrive fréquemment, et cette personne n’est pas au niveau. Encore une fois, les exceptions varient, votre expérience peut varier.
Conor Doherty: Exactement. Ma question est donc la suivante : y a-t-il eu des situations où vous êtes intervenu pour évaluer une entreprise, où vous étiez là pour évaluer tous les éléments dont vous avez parlé – le code, la manière dont l’équipe travaille, la capacité à atteindre l’objectif avec les ressources dont elle dispose – mais où l’objectif final de l’entreprise était tout simplement absurde ? Par exemple, c’est 2008 et cette entreprise est déterminée à ramener la cassette VHS, comme quelque chose de totalement insensé que vous considérez comme un énorme gâchis d’argent, de temps et de ressources.
Joannes Vermorel: Oh oui, cela arrive. N’hésitez pas, mais ne donnez aucun nom.
Conor Doherty: Non, la chose est que certaines technologies logicielles évoluent très rapidement. Par exemple, au cours des deux dernières années, j’ai audité pas mal d’entreprises qui étaient dans le NLP. Ces entreprises ont été lancées en 2018 ou 2019 et se sont lancées dans cette vague d’IA en développant des technologies de NLP, de traitement du langage naturel, mais en pré-LLM, avant l’avènement des large language models. Il existait une littérature énorme de modèles NLP et de machine learning, deep learning, qui ne concernaient pas les LLM. Les LLM ont constitué un événement d’extinction pour toutes ces technologies NLP.
Joannes Vermorel: Oui, il y avait de nombreuses entreprises pour lesquelles ma conclusion était la suivante : cette entreprise a développé 20 modèles NLP assez sophistiqués, mais ils sont tous complètement obsolètes. Les LLMs surpassent uniformément tout cela. Vous pouvez simplement jeter tout le tech stack et repartir de zéro avec un LLM en tête, et vous serez meilleur. Il n’y a rien à récupérer. Cela arrive assez fréquemment, peut-être une sur 10, une sur 20, où la technologie est tout simplement obsolète pour une raison ou une autre. Parfois, les gens n’ont pas exactement prévu quel sera le remplacement, mais oui, quand je constate que cette approche se résume à résoudre un problème qui est déjà résolu.
Conor Doherty: Habituellement, le fait est que ce n’est pas absurde dans le sens où ces personnes seraient des idiots. Il y a un problème à résoudre, et ils ont développé quelque chose d’intéressant, mais il existe quelque chose de bien meilleur qui a déjà été trouvé et possiblement gratuit. Cette solution n’est pas encore populaire, elle n’est pas super connue pour l’instant. Je pense que les LLMs sont vraiment le cas extrême où, du fait que ces entreprises se trouvaient dans une situation quelque peu désespérée parce qu’elles savaient que les LLMs arrivaient et qu’ils constituaient un événement d’extinction, elles se sont lancées dans cette voie. Mais vous êtes le fondateur d’une entreprise, vous avez déjà investi l’argent que vous avez levé lors des tours de seed, et maintenant vous vous retrouvez face à la perspective que votre technologie est en quelque sorte sans valeur. Vous tentez peut-être de décrocher un investissement qui vous permettrait de redévelopper la technologie. Difficile.
Joannes Vermorel: Dans ce genre de situation, mon point de vue n’est pas de dire aux investisseurs : “N’investissez pas.” Mon message est que le tech stack qu’ils possèdent ne vaut rien. Si les personnes sont compétentes, il pourrait encore y avoir une raison d’investir en elles, mais simplement à une valorisation bien plus basse puisque ce qu’ils ont n’est plus un atout technologique, il est complètement dépassé. Ce n’est plus un atout, c’est un passif.
L’équipe est fonctionnelle, et la trajectoire en termes de développement de la technologie est folle. Parfois, il s’agit aussi de vérifier, par exemple, que les ressources en cloud computing sont bien maîtrisées. Parfois, vous avez des entreprises qui mal gèrent leurs ressources cloud. Le cloud est fantastique ; le paiement à l’usage signifie que le ciel est la limite. Vous pouvez lancer des tonnes de machines virtuelles, une masse de stockage, et tout le reste. Parfois, les entreprises se lancent un peu dans l’excès et finissent par dépenser bien trop pour des ressources cloud qu’elles ne devraient pas. Cela dépend de ce qu’elles font. Combien devriez-vous payer pour des ressources cloud ? Eh bien, cela dépend vraiment de ce que vous cherchez à accomplir sur le cloud et si cela a du sens que vous payiez autant. Est-ce une réussite bien réalisée, votre logiciel est-il extrêmement performant, ou est-ce vraiment mauvais et vous jetez simplement de l’argent par les fenêtres ? Probablement que se retrouver avec des tonnes d’argent supplémentaire à brûler n’est tout simplement pas la bonne approche. Vous devriez probablement régler ces problèmes avant de vous voir attribuer quelques millions de plus. Si vous manquez d’argent, vous ne pouvez pas vous discipliner pour éviter de brûler de l’argent à cause de dépenses inconsidérées en ressources informatiques. Les chances que vous deveniez avisé une fois que vous aurez beaucoup plus d’argent sont très minces.
Conor Doherty: Il me vient à l’esprit, et à ce propos, nous avons en réalité une autre vidéo sur le sujet des ressources informatiques, alors consultez la playlist pour cela. Mais en ce qui concerne l’argent, quand vous parlez de finances, je sais que lorsque l’on parle de supply chain, on évoque l’impact financier net de chaque décision que vous prenez. Adoptez-vous la même approche lorsque vous évaluez une entreprise technologique ? Regardez-vous quelle orchestration est la plus bénéfique financièrement, ou bien est-ce simplement la meilleure technologie, quel que soit le prix ?
Joannes Vermorel: Non, non, non. Chaque startup dispose de ressources limitées. Le problème avec les listes de contrôle, c’est qu’elles proposent une vision absolue, en affirmant qu’il faut faire ceci, cela et encore ceci. Ma perspective est toujours complètement relative à la maturité de l’entreprise.
Conor Doherty: Oui, exactement, selon leurs propres termes.
Joannes Vermorel: Par exemple, vous ne voudriez pas qu’une petite entreprise se lance dans une certification ISO, ce serait de la pure folie. Ce serait un gaspillage total de ressources, à moins que ce ne soit un marché hyper-réglementé où vous ne pouvez pas survivre sans cette certification. Ce que j’examine, c’est à quel point vous savez utiliser vos ressources limitées pour obtenir le maximum de rendement. Je pars du principe que votre direction est bonne, qu’en fin de compte, si vous réussissez, vous allez gagner de l’argent. Mais, tout de même, en prenant pour acquis vos orientations commerciales, je dis, d’accord, admettons que si cela est réalisé, alors vous serez compétitif sur ce marché et il y aura de l’argent à gagner. J’adopte cette hypothèse. Maintenant, chaque dollar ou euro dépensé pour devenir le leader de ce marché est-il utilisé judicieusement ? Absolument. Cela peut se traduire, par exemple, par le recrutement des bons talents ? Parfois, ils dépensent trop peu. Il arrive que l’entreprise atteigne un certain succès et qu’elle ne se sépare pas de personnes initialement embauchées simplement parce qu’elles étaient super bon marché. Cela arrive assez fréquemment avec les startups technologiques. Surtout lorsque le fondateur n’est pas un fondateur technologique, mais un fondateur commercial, et que vous avez ensuite le CTO qui a été, à l’origine, le premier ingénieur logiciel recruté par l’entreprise. Cela se produit fréquemment, et cette personne n’est pas toujours à la hauteur. Là encore, les exceptions varient, chacun son cas.
Conor Doherty: Exactement. Ma question est donc la suivante : avez-vous déjà rencontré des situations où, en évaluant une entreprise, vous avez eu l’impression que son objectif ultime était tout simplement absurde ? Par exemple, c’est 2008, et cette entreprise est déterminée à ramener la cassette VHS. Quelque chose de complètement insensé que vous estimez être un énorme gaspillage d’argent, de temps et de ressources.
Joannes Vermorel: Oh oui, cela arrive.
Conor Doherty: N’hésitez pas à partager, mais ne donnez aucun nom.
Joannes Vermorel: Certaines technologies logicielles évoluent assez rapidement. Par exemple, au cours des deux dernières années, j’ai audité pas mal d’entreprises travaillant dans le domaine du NLP. Ces entreprises ont été créées en 2018 ou 2019, et elles se sont lancées dans cette vague d’IA en développant des technologies de NLP (Natural Language Processing), mais pré-LLM (Large Language Models). Il existait une littérature énorme de modèles NLP, de machine learning, de deep learning, mais pas de LLMs. Les LLMs ont constitué un événement d’extinction pour toutes ces technologies NLP. Pour ces entreprises, ma conclusion était qu’elles avaient développé 20 modèles NLP assez sophistiqués, mais qu’ils sont tous complètement obsolètes. Les LLMs surpassent uniformément tout cela. Vous pouvez simplement jeter le tech stack et repartir de zéro avec un LLM en tête. Il n’y a rien à récupérer. Cela arrive assez fréquemment, peut-être une sur 10 ou une sur 20, où la technologie est tout simplement obsolète pour une raison quelconque. Parfois, les gens n’ont pas vu exactement quelle serait la solution de remplacement. Quand je constate que cette approche va simplement être adoptée, cela signifie que vous résolvez un problème qui est déjà résolu. Habituellement, ce n’est pas absurde dans le sens où ces personnes seraient des idiots. Il y a un problème à résoudre, et elles ont développé quelque chose d’intéressant, mais il existe quelque chose de bien meilleur qui a déjà été trouvé et possiblement gratuit. Cette solution n’est pas encore populaire, elle n’est pas super connue. Les LLMs représentent un cas extrême où des entreprises étaient en quelque sorte désespérées parce qu’elles savaient ce qui arrivait, et c’était un événement d’extinction. Vous êtes le fondateur d’une entreprise, vous avez déjà investi l’argent levé lors des tours de seed pour cela, et maintenant vous vous retrouvez avec la perspective que votre technologie est en quelque sorte sans valeur. Vous tentez peut-être de décrocher un investissement qui vous permettrait de redévelopper la technologie. C’est difficile. Mon point de vue n’est pas de dire aux investisseurs de ne pas investir. Mon message est que le tech stack qu’ils possèdent ne vaut rien. Si les personnes sont compétentes, il pourrait encore y avoir matière à investir en elles, mais à une valorisation beaucoup plus basse, car ce qu’ils possèdent n’est plus un atout, c’est un passif.
Conor Doherty: À l’autre bout du spectre, vous est-il déjà arrivé de visiter une entreprise et de repartir en vous disant : “Je viens de rencontrer le prochain Elon Musk” ? Genre, ce type est un génie, ils sont assis sur un diamant.
Joannes Vermorel: Sur ce plan, non. Mais oui, il m’est arrivé de ressentir une légère jalousie par rapport à ma propre entreprise. Surtout lorsque des acteurs occupent des niches aussi magnifiques. Il existe tellement de belles niches. Ce qui me rend le plus jaloux, ce sont des problèmes élégants et hyper de niche. Personne ne sait même que ce problème existe. Il s’avère que des dizaines de millions, voire peut-être un milliard, sont en jeu. C’est un marché de niche, et certaines personnes proposent une solution pour cette niche, et c’est sublime. C’est très simple, direct et précis. Au lieu de se retrouver dans un marché hyper compétitif, par exemple, Lokad faisant l’optimization de la supply chain, nous avons plus d’un millier de concurrents dans le monde. C’est un marché très saturé. Certains concurrents sont des entreprises valant plusieurs milliards. Le paysage concurrentiel est rude. Parfois, je rencontre des entreprises qui n’ont littéralement aucun concurrent. Elles sont uniques. Leurs clients sont satisfaits, elles disposent d’une solution vraiment adaptée à un problème de niche dont je n’avais jamais entendu parler auparavant.
Conor Doherty: Des exemples là-dessus, ou ce serait trop révélateur ?
Joannes Vermorel: Non, ce serait malheureusement trop révélateur. J’essaie, mais en fin de compte, pensez à, disons, tout ce qui est super spécialisé.
Pensez à la maintenance spécialisée d’une plateforme pétrolière en mer. Il y a une multitude de tâches à accomplir, et certaines opérations spécifiques nécessitent un logiciel en soutien. Il existe des entreprises qui offrent ce type de service. Pensez à chaque niche qui nécessite probablement des solutions très dédiées.
Vous avez de nombreuses situations où l’on peut imaginer combien d’équipements technologiques un chirurgien utilise dans une salle d’opération. Une multitude d’équipements, même si vous souhaitez mesurer quelque chose. Par exemple, dans ce bâtiment, ils disposaient d’un dispositif de contrôle pour détecter la présence d’amiante. Il y avait un équipement équipé d’un logiciel pour détecter l’amiante dans ce bâtiment. Il existe quelque part une entreprise qui fait cela. Ces niches très spécifiques peuvent sembler petites, mais quand on regarde le marché global, ce n’est pas si minime.
Ces niches très réduites peuvent représenter quelques centaines de millions de dollars à l’échelle mondiale, et une entreprise a l’opportunité de capter 50 % de parts de marché parce qu’il n’y a aucun concurrent. L’alternative, c’est que les gens utilisent des méthodes traditionnelles papier et crayon.
Conor Doherty: Au fil de ces 10 années et après avoir vu une grande variété d’exemples, y a-t-il des bonnes pratiques générales et des mauvaises pratiques que vous avez remarquées en matière de logiciels ou de startups ? Commençons par ce qu’il faut absolument éviter et terminons sur une note positive. Alors, les choses à éviter absolument ?
Joannes Vermorel: Si vous ne vous souciez pas de votre technologie, elle finira par vous exploser à la figure. Le manque de soin est fatal. Chaque fois que je vois des entreprises où les gens ne se préoccupent pas de leur technologie, celle-ci est généralement complètement médiocre.
Conor Doherty: Définissez ce que vous entendez par « ne pas se soucier ». Est-ce qu’ils ne s’intéressent pas à l’apprendre, ou s’y intéressaient-ils autrefois et ne le font plus maintenant, ou bien est-ce un manque de compétence ? Que voulez-vous dire par là ?
Joannes Vermorel: La meilleure façon de le décrire est la suivante : quand le CTO prend sa douche, pense-t-il à sa technologie ou au golf ? Les personnes qui se soucient vraiment ont une certaine intensité. Cela ne s’arrête pas aux heures de bureau ; cela va bien au-delà. Elles sont extrêmement curieuses, enthousiastes et passionnées. Elles veulent vraiment faire ce qu’il faut. Il y a cet élément d’une légère folie où il ne s’agit pas seulement de faire ce qui est bon pour le client, mais aussi de faire ce qui est bon pour la technologie elle-même.
Concevez-vous quelque chose de véritablement beau ? Il y avait une anecdote à propos de Steve Jobs. Il voulait que l’iPhone soit esthétiquement plaisant même à l’intérieur. Lorsqu’on le démonte, les composants internes de l’iPhone se révèlent élégants par eux-mêmes, avec un choix judicieux de couleurs et autres détails. Ce niveau de soin reflète le fait que vous vous souciez profondément, non seulement de l’apparence extérieure, mais aussi des parties technologiques que aucun client ne verra jamais.
Quand les gens ne se soucient pas, c’est vraiment mauvais. Le pire, c’est probablement lorsque les entreprises technologiques externalisent le développement de leurs technologies à des contributeurs freelances. Peu importe que ces freelances soient bons ou mauvais ; le résultat net est que la technologie se retrouve généralement dans un état chaotique.
Conor Doherty: Je pense que la plupart seraient d’accord pour dire que la passion intrinsèque et l’envie de bien faire sont des qualités fantastiques. Cela dit, si vous n’avez que 20 minutes avec le CTO, comment évaluer ces intangibles sans liste de contrôle ?
Joannes Vermorel: Une personne dotée d’intensité me dira : “Nous avons choisi cette technologie pour telle raison.” Ils connaissent le pourquoi. Ce n’est pas simplement : “J’avais besoin d’une interface web, alors j’en ai choisi une.” Ils ont des opinions sur leurs choix technologiques. Les personnes passionnées ont tant d’opinions que cela transparait. Elles ne peuvent s’en empêcher. À chaque fois que je touche à une partie de la technologie, elles me disent : “Nous la faisons de cette manière pour ces raisons.”
Conor Doherty: C’est cette passion qui les intéresse.
Joannes Vermorel: Oui, et on peut voir l’intensité de leur réflexion. Il ne s’agit pas simplement d’une technologie réalisée parce qu’il y avait des exigences. Ceux qui produisent du code à la chaîne adoptent une approche très banale où les exigences proviennent de l’équipe commerciale, et ils se contentent de les implémenter. C’est la recette d’un tech stack absolument médiocre.
Conor Doherty: Par exemple, si vous aviez audité Steve Jobs par le passé et qu’il vous avait dit, “Regardez l’intérieur de ce téléphone, je l’ai rendu beau”, votre rapport dirait qu’il est passionné, mais c’est une chose folle sur laquelle dépenser de l’argent.
Joannes Vermorel: Non, non. La question est : a-t-on l’impression qu’ils cherchent à se distraire, ou bien se contentent-ils d’apporter une touche finale supplémentaire ? Ces éléments ne sont peut-être pas très coûteux. C’est simplement une question d’intensité. Vous en faites quelques pourcents de plus afin d’obtenir un résultat vraiment soigné et agréable. Ce n’est pas de la folie. Ceux qui en font trop subissent généralement un effet de second système. C’est lorsque qu’une équipe d’ingénieurs, lors de sa deuxième tentative, investit outre mesure dans des choses inutiles parce que la première fois a échoué en raison d’une technologie médiocre.
The most frequent case is when people over-invest in scalability that they won’t need anytime soon. → Le cas le plus fréquent est lorsque les gens investissent trop dans l’évolutivité dont ils n’auront pas besoin de sitôt. Ils disent, “Regardez notre belle architecture; elle peut gérer 10 millions d’utilisateurs.” Combien d’utilisateurs avez-vous à ce stade ? “Oh, 200.” Il existe un décalage énorme entre ce qui est nécessaire et la sur-ingénierie.
Also, the people who are patient about the wrong things. Do you have a patience that is for a certain elegance and beauty of technology for itself, or are you going through some kind of dogma? In software industries, you have all sorts of dogmas floating around. We need to do it like Scrum, or we need to do domain-driven development, or test-driven development, or microservices. There are plenty of guru-esque takes in the software industry, and you have people who are zealots for this. When I say intensity, I mean people who love what they are crafting but who are not zealots about a specific ideology. Zealots do things that completely mismatch even their own practical requirements. They say, “Oh, but we have to do it that way because it’s test-driven design.” The fact that it’s test-driven design is not a justification for doing it that way. Does it really make sense to do it that way with regard to whatever problems you have? → Également, il y a les personnes qui font preuve de patience pour les mauvaises choses. Disposez-vous d’une patience pour une certaine élégance et beauté de la technologie en elle-même, ou êtes-vous soumis à une sorte de dogme ? Dans l’industrie du logiciel, toutes sortes de dogmes flottent autour. Nous devons faire comme Scrum, ou nous devons pratiquer le domain-driven development, le test-driven development ou adopter des microservices. Il existe de nombreuses approches dignes de gourous dans l’industrie du logiciel, et certains y sont fanatiques. Quand je parle d’intensité, je fais référence à des personnes qui aiment ce qu’elles créent sans être fanatiques d’une idéologie spécifique. Les fanatiques font des choses qui sont complètement en décalage avec leurs propres exigences pratiques. Ils disent, “Oh, mais nous devons faire ainsi parce que c’est du design piloté par les tests.” Le fait que ce soit du design piloté par les tests ne justifie pas de procéder ainsi. Est-ce vraiment logique de faire de la sorte par rapport aux problèmes que vous rencontrez ?
Conor Doherty: And in terms of the best practices, don’t just say the opposite of what you just said. Are there any off the top of your head things that, when you see them, you think, “Oh, that’s a good sign”? → Conor Doherty: Et en termes de meilleures pratiques, ne vous contentez pas de dire le contraire de ce que vous venez de dire. Y a-t-il, spontanément, des éléments pour lesquels, en les voyant, vous pensez : “Oh, c’est bon signe” ?
Joannes Vermorel: Clear writing. You said that before. Clear writing. Every single piece needs to be to the point, sharp, and concise. Do you have pages of comments in the code that are just bureaucratic, like, “Oh, we need to comment this”? Is there a template, and you have a page of comments nobody is going to read? Or do you have super tight comments that are very interesting? Just by reading one comment, it sheds light on the entire code file. When I look at the tickets, is your problem statement written in a way that is very clear, or is it an incomprehensible mess? When you have a technical challenge, is there a very articulate discussion of the problem and the possibilities, or do you have a crappy slide with insane bullet points that say nothing? Quality of writing is one of the telltale signs. Another one is when people use unusual technologies that still happen to be very good choices. If they use an unusual piece of technology, very frequently it is just out of ignorance. They didn’t know there was a much more mainstream solution that would be much better. Usually, it’s a negative, but when it turns out that a relatively rare piece of tech is surprisingly to the point for what they’re doing, that’s very good. It means they have explored the technological landscape, especially the open-source technological landscape, in a very extensive way. That’s very nice. Nowadays, nobody would be surprised if people say, “Oh, we’re using Python, PostgreSQL, Tailwind for CSS, React.” Those are components every halfway competent software engineer knows about. But if they know something super specific that really fits their problem, that is also very interesting. → Joannes Vermorel: Une écriture claire. Vous l’avez déjà dit. Une écriture claire. Chaque élément doit être précis, incisif et concis. Avez-vous des pages de commentaires dans le code qui sont purement bureaucratiques, du genre “Oh, il faut commenter ceci” ? Existe-t-il un modèle avec une page de commentaires que personne ne lira ? Ou bien avez-vous des commentaires hyper condensés et très intéressants ? Rien qu’en lisant un commentaire, on comprend l’ensemble du fichier de code. Lorsque je consulte les tickets, l’énoncé de votre problème est-il rédigé de manière limpide, ou est-ce un bazar incompréhensible ? Quand vous êtes confronté à un défi technique, y a-t-il une discussion très articulée du problème et des possibilités, ou bien disposez-vous d’une diapositive médiocre avec des bullet points absurdes qui ne disent rien ? La qualité de l’écriture est l’un des signes révélateurs. Un autre indice est lorsque les gens utilisent des technologies inhabituelles qui s’avèrent néanmoins être d’excellents choix. S’ils optent pour une technologie peu commune, c’est très souvent par ignorance. Ils ne savaient pas qu’il existait une solution bien plus grand public et bien meilleure. Habituellement, c’est négatif, mais lorsqu’il s’avère qu’une technologie relativement rare est étonnamment parfaitement adaptée à ce qu’ils font, c’est très positif. Cela signifie qu’ils ont exploré le paysage technologique, en particulier le paysage open-source, de façon très approfondie. C’est vraiment appréciable. De nos jours, personne ne serait surpris d’entendre, “Oh, nous utilisons Python, PostgreSQL, Tailwind for CSS, React.” Ce sont des composants que tout ingénieur logiciel à moitié compétent connaît. Mais s’ils maîtrisent quelque chose de très spécifique qui correspond parfaitement à leur problème, c’est également très intéressant.
Conor Doherty: Cool. Well, we’ve been going for about an hour. I’m mindful of time, so to wrap things up, are there any closing thoughts you’d like to share with everybody? → Conor Doherty: Cool. Bon, cela fait environ une heure que nous discutons. Je suis conscient du temps, donc, pour conclure, avez-vous des réflexions finales que vous aimeriez partager avec tout le monde ?
Joannes Vermorel: Yes. I think what surprises me the most in this decade of audits is how frequently tech companies can literally spend years and sometimes successive rounds of investment with nobody having a look at the tech. You would think that Theranos, this big fraud, was an exception. Such a massive investment, and nobody did any due diligence of the technology. But the funny thing is that it’s the norm. For me, what is very intriguing is how rare these technological audits are. When I talk with those startup founders, they usually tell me, “We had no idea you would be asking those sorts of questions.” They think I will come with this insane, stupid checklist. Just imagine Theranos; people would have easily fooled the checklist. There were plenty of checklists around, like, “Are you compliant with this and that?” Yes, yes, yes, yes. But the core question, which was, “Is your blood analysis technology real?” Nobody asked those questions. They were super basic. → Joannes Vermorel: Oui. Ce qui me surprend le plus durant cette décennie d’audits, c’est la fréquence à laquelle les entreprises technologiques peuvent littéralement consacrer des années, et parfois plusieurs cycles d’investissement successifs, sans que personne n’examine réellement la technologie. On pourrait penser que Theranos, cette énorme fraude, était une exception. Un investissement aussi colossal, et pourtant personne n’a réalisé de due diligence sur la technologie. Mais ce qui est amusant, c’est que c’est la norme. Pour moi, ce qui est vraiment fascinant, c’est la rareté de ces audits technologiques. Quand je discute avec ces fondateurs de startups, ils me disent généralement, “Nous n’avions aucune idée que vous poseriez ce genre de questions.” Ils pensent que je vais débarquer avec une liste de contrôle insensée et stupide. Imaginez Theranos ; les gens auraient facilement trompé la liste de contrôle. Il y avait plein de listes de contrôle, du genre “Êtes-vous conforme à ci et à ça ?” Oui, oui, oui, oui. Mais la question centrale, qui était “Votre technologie d’analyse sanguine est-elle réelle ?” Personne ne posait ces questions. Elles étaient superficielles.
Conor Doherty: This comes back to the point you made before about skin in the game. If venture capitalists are going to invest millions in your company, they have skin in the game. → Conor Doherty: Cela revient au point que vous avez évoqué précédemment à propos du skin in the game. Si les capital-risqueurs doivent investir des millions dans votre entreprise, ils ont la peau dans le jeu.
Joannes Vermorel: The thing I find very surprising is that usually, even if I’m coming in the third round, nobody has had a serious look at the technological stack. It’s very strange. You have auditors who are just ticking boxes, but in my book, those do not count. They just pretend to do the work. They don’t do anything of substance. It is super easy to fool those people because all you have to do is lie. Just say, “Do you do that?” “Yeah, we do it.” “Show us.” You show something that doesn’t make any sense. The auditor is not a tech person, so you could show him anything, and he would just say, “Okay, box ticked.” At the end of those audits, it’s very intriguing. In classical audits, the auditor will say, “Please sign this paper that says you didn’t lie to us, and if you lied, we decline all responsibility.” My take is that I’m certainly not going to do that. I do not assume that people are telling me the truth. That’s why I want to see the codebase. Yes, you can fool me and tell me tons of things, but when we look at the codebase, forging a codebase, forging thousands of commits, forging hundreds of tickets, forging all the supporting documents, that is way more difficult. What surprises me is that the cost is one day of audits. Yes, I’m not exactly cheap, but still, it’s one day. Even after doing these audits for more than a decade, I still notice that when I come, even in the second or third rounds, nobody has really challenged the tech. People just assume it’s good, it works, they will do their roadmap. No check whatsoever. For me, that’s a little bit baffling. → Joannes Vermorel: Ce qui me surprend le plus, c’est qu’habituellement, même si j’arrive lors du troisième cycle, personne ne s’est réellement penché sur la pile technologique. C’est très étrange. On trouve des auditeurs qui se contentent de cocher des cases, mais à mes yeux, cela ne compte pas. Ils font semblant de travailler, ils ne font rien de concret. Il est extrêmement facile de tromper ces personnes, car tout ce que vous avez à faire, c’est mentir. Il suffit de dire, “Est-ce que vous faites cela ?” “Oui, nous le faisons.” “Montrez-nous.” Vous leur montrez quelque chose qui n’a aucun sens. L’auditeur n’étant pas un expert technique, vous pourriez lui présenter n’importe quoi, et il dirait simplement, “D’accord, case cochée.” À la fin de ces audits, c’est très intrigant. Dans les audits classiques, l’auditeur dira : “Veuillez signer ce document attestant que vous ne nous avez pas menti, et si vous avez menti, nous déclinons toute responsabilité.” Pour ma part, je ne vais certainement pas faire cela. Je ne présume pas que les gens me disent la vérité. C’est pourquoi je veux voir la codebase. Oui, vous pouvez me duper en me racontant des tas de choses, mais lorsque nous examinons la codebase, falsifier une codebase, falsifier des milliers de commits, des centaines de tickets, et tous les documents supports, c’est bien plus difficile. Ce qui me surprend, c’est que le coût ne représente qu’une journée d’audit. Oui, je ne suis pas exactement bon marché, mais quand même, c’est une journée. Même après avoir réalisé ces audits pendant plus d’une décennie, je remarque encore qu’à mon arrivée, même lors des deuxième ou troisième cycles, personne n’a vraiment remis en question la technologie. Les gens supposent simplement que c’est bon, que ça fonctionne, et qu’ils suivront leur feuille de route. Aucune vérification, rien du tout. Pour moi, c’est plutôt déconcertant.
Conor Doherty: Well, hopefully, something we’ve discussed today will make a difference, perhaps even inspire a few people to reach out to you. You’re also available for bat mitzvahs and birthdays, I believe. → Conor Doherty: Eh bien, j’espère que ce dont nous avons discuté aujourd’hui fera une différence, et peut-être même inspirera quelques personnes à vous contacter. Vous êtes également disponible pour les bat mitzvahs et les anniversaires, je crois.
Joannes Vermorel: Yes. → Joannes Vermorel: Oui.
Conor Doherty: Well, Joannes, thank you very much for your time and for answering all my questions. Thank you very much, and thank you for watching. We’ll see you next time. → Conor Doherty: Eh bien, Joannes, merci beaucoup pour votre temps et pour avoir répondu à toutes mes questions. Merci infiniment, et merci de nous avoir regardés. À la prochaine.
