Pourquoi j'ai quitté un poste senior en AI pour construire un moteur de conversion inbound

Le moment où j'ai su que je devais construire ça

On était en 2023. Je venais de passer deux ans chez NielsenIQ à construire des modèles de prévision pour les biens de consommation qui sont passés de zéro à 7 millions de dollars d'ARR. Avant ça, six ans à diriger l'AI chez Deutsche Bank, où l'équipe que j'ai construite a atteint 10 millions de dollars d'ARR en deux ans. Sur le papier, une carrière AI corporate solide.

Et je continuais à voir le même phénomène se reproduire : un logiciel brillant — une librairie, un outil développeur, un produit d'infrastructure — se lançait sur GitHub, gagnait un amour sincère de ses utilisateurs, accumulait les stars, puis échouait complètement à convertir cet amour en business. Les fondateurs passaient leurs nuits à répondre aux mêmes questions support. Les personnes avec une vraie intention d'achat repartaient silencieusement parce que personne n'était là pour les capter.

J'avais vu ce pattern des deux côtés. À la banque, j'avais évalué des centaines de produits fournisseurs et regardé des petites équipes perdre des deals non pas parce que leur technologie était moins bonne, mais parce qu'elles ne pouvaient pas répondre assez vite. Chez NielsenIQ, j'avais vu notre propre outillage interne être sous-utilisé parce que personne n'avait le temps de gérer la charge support. Le revenu restait sur la table — de façon constante, prévisible et inutile.

Le gap n'était pas un gap produit. C'était un gap de présence.

Ce que j'ai appris chez Deutsche Bank sur le revenu enterprise

Quand j'ai rejoint Deutsche Bank en 2019, j'étais chargé de construire une équipe AI au sein de leur division Securities Services. On vendait des produits AI en interne et aux clients institutionnels. La leçon que j'ai apprise rapidement était contre-intuitive : les acheteurs enterprise n'achètent pas le meilleur produit. Ils achètent le produit en lequel ils ont confiance.

La confiance, à ce niveau, vient de la réactivité. De la capacité à répondre à leur question spécifique — leur question conformité, leur question intégration, leur question sécurité — au moment où ils la posent. Pas deux jours plus tard dans un email. Pas dans une démo planifiée de 30 minutes dans trois semaines. Tout de suite.

On a construit des systèmes pour aider notre équipe à répondre plus vite. On a entraîné l'AI sur notre documentation. On a automatisé la qualification du premier contact. Et ça a marché : des conversations qui auraient calé sont devenues des deals. C'est de là que venaient les 10 millions de dollars d'ARR — pas d'un meilleur produit seul, mais du fait d'être réellement présent quand les prospects avaient des questions.

J'ai rangé cette leçon. À l'époque, je ne savais pas que j'accumulais la thèse d'une entreprise.

Le bot de documentation qui est devenu un business

Avance rapide jusqu'en 2023. J'avais quitté NielsenIQ, je réfléchissais à ce que je voulais construire, et je suis parti d'une observation simple de ma propre expérience développeur : je cherchais toujours la même documentation. Je lisais les mêmes sections README. Je posais les mêmes questions setup dans les communautés Slack.

J'ai donc construit un moteur de recherche de documentation — un bot qui pouvait répondre aux questions sur une librairie en lisant sa doc. Simple, personnel, utile pour moi.

Je l'ai partagé avec quelques amis qui maintenaient des librairies open source. En quelques jours, ils l'utilisaient tous. En quelques semaines, ils rapportaient que leurs canaux Discord étaient plus calmes, que leurs GitHub Issues avaient moins de questions « comment je fais », et qu'ils passaient plus de temps à shipper des features. Bereket Engida, qui maintient Better Auth, m'a dit que son activité Discord avait augmenté de 10x depuis le déploiement du bot — parce que les gens obtenaient enfin des réponses assez vite pour rester et continuer à poser des questions.

C'était le moment. Je ne résolvais pas juste un problème de documentation. Je résolvais un problème de présence. Un problème de revenu.

Le pattern dont personne ne parlait

Une fois que j'ai commencé à le chercher, je le voyais partout. À travers les communautés open source que je connaissais, les produits SaaS que j'utilisais, les outils développeur que j'avais évalués dans mes rôles corporate — la même dynamique se reproduisait constamment.

Un prospect arrive. Il a une vraie question. La question est le premier signal d'intention. Mais les seules options sont : envoyer un email (trop d'effort) ou soumettre un formulaire de contact (qui va dans une file d'attente). Alors il ferme l'onglet. Il n'a pas rebondi parce que le produit n'était pas le bon. Il a rebondi parce que la friction de l'engagement était plus élevée que le bénéfice de rester.

Et les chiffres derrière le pipeline perdu sont vertigineux. 60 % des conversations génératrices de revenu ont lieu en dehors des heures de bureau. 78 % des acheteurs vont avec le premier fournisseur à répondre. Le temps de réponse moyen en B2B est de 42 heures. Ces trois statistiques, prises ensemble, décrivent un seau percé dans lequel chaque petite équipe verse son trafic.

Pourquoi je l'ai appelé moteur de conversion inbound AI

J'ai longuement hésité sur comment décrire ce qu'est Clarm. « AI chatbot » était trop petit — ça impliquait un widget dans un coin répondant aux FAQs. « Automatisation support » manquait entièrement la dimension revenu. « Capture de leads » sonnait comme un formulaire.

Le cadre qui a finalement cliqué est ce que j'avais vu chez Deutsche Bank : un revenue desk. Une fonction au sein d'une banque responsable d'être présente au moment où un client a besoin de quelque chose lié au revenu — un trade, une question de pricing, une demande de risque. Le desk existe pour qu'aucun signal client ne passe inaperçu et qu'aucune conversation ne meure en attendant qu'un humain se rende disponible.

C'est exactement ce que je voulais donner à chaque fondateur technique : l'équivalent d'un revenue desk senior staffé 24/7, sur chaque canal qu'il opère, qui ne coûte pas 150 000 $ par an et n'a pas besoin d'être managé.

Un moteur de conversion inbound AI. Clarm.

Ce que les premiers déploiements m'ont appris

Les premiers résultats ont validé la thèse plus vite que je ne l'espérais. GiveLegacy, une entreprise de santé, a déployé Clarm sur son site. En 90 jours, leurs conversations inbound sont passées d'environ 760 demandes email à 4 624 conversations gérées par l'AI — un lift de 6,1x depuis le même trafic. 25,2 % montraient une intention d'achat. 60 % ont eu lieu en dehors des heures de bureau. Le canal est passé de 0 $ à leur source de revenu inbound n°1 en 90 jours.

Better Auth est passé de 8 000 à 22 000 GitHub stars en trois mois après le déploiement de Clarm. Pas parce que le produit a changé. Parce que l'expérience communautaire a changé — les gens obtenaient des réponses assez vite pour rester engagés, contribuer et en parler aux autres.

c/ua, une entreprise de framework agent, a utilisé l'enrichissement de Clarm pour identifier quels utilisateurs GitHub construisaient des systèmes de production. Cette identification a directement mené à leur premier client enterprise.

Le pattern tenait à travers la santé, l'open source et le SaaS. Le gap était le même partout. La solution aussi.

Ce que j'ai abandonné (et pourquoi ça en valait la peine)

On me demande parfois si la stabilité d'un poste senior en AI corporate me manque. Honnêtement : pas une seule fois.

Quand j'étais chez Deutsche Bank, je construisais des systèmes qui rendaient une grande institution légèrement plus efficiente. Quand j'étais chez NielsenIQ, j'améliorais des prévisions pour des entreprises de biens de consommation. Les deux étaient significatifs. Aucun des deux n'allait dans la direction que je voulais donner à ma vie professionnelle.

En construisant Clarm, je résous le problème auquel je ne pouvais pas arrêter de penser. Je parle à des fondateurs qui construisent des choses qui comptent — des produits qui existent parce que quelqu'un a assez tenu pour écrire le code, obtenir les GitHub stars et garder la communauté en vie. Et je leur donne une pièce d'infrastructure qui fait qu'ils n'ont pas à choisir entre construire et vendre.

Je crois que le monde a besoin de plus de fondateurs. Pas moins. Le rythme accéléré de l'AI signifie que plus de problèmes que jamais sont résolvables. Mais la plupart des personnes qui essaient de résoudre ces problèmes échoueront non pas à cause de mauvaises idées ou de mauvais engineering, mais parce qu'elles manqueront de runway avant que le revenu ne rattrape le produit. Clarm est ma tentative de changer ce ratio.

Où nous en sommes aujourd'hui

Clarm est une entreprise soutenue par Y Combinator (YC X25). Nous traitons des milliers de conversations inbound chaque semaine à travers le chat web, Discord, Slack et GitHub. Nous sommes conformes HIPAA et SOC 2. Nous supportons le déploiement on-prem pour les industries régulées. Clarm opère depuis San Francisco et Zurich. Nous avons une équipe aussi sérieuse que moi sur ce problème.

Et je réponds toujours personnellement à chaque email envoyé à [email protected]. Parce que l'ironie de diriger une entreprise dont tout le propos est que les fondateurs ne devraient pas avoir à répondre manuellement à chaque question ne m'échappe pas — et parce que parler directement aux personnes que nous servons reste le meilleur moyen de comprendre ce que nous devons construire ensuite.

Si tu es un fondateur assis sur du trafic qui ne convertit pas, ou une équipe noyée sous les mêmes questions support, ou une équipe engineering qui perd des deals enterprise parce que le temps de réponse tue les conversations overnight — j'aimerais sincèrement te parler. Réserve 20 minutes avec moi. Pas de script commercial. Juste une conversation sur le problème.

FAQ

Pour aller plus loin

Si ça t'a parlé, tu voudras peut-être lire le problème de pipeline caché que chaque fondateur technique ignore ou comment le founder-led sales casse à grande échelle et quoi construire à la place.