Avant de fabriquer des millions de robots, il faut les concevoir. Retour sur une levée qui parie sur le vrai goulot d'étranglement de la physical AI, et sur un go-to-market entièrement porté par les ingénieurs.

Hestus a bouclé un tour de seed de 7,4 millions de dollars pour construire ce qu'elle appelle l'intelligence mécanique : une IA qui comprend la géométrie et les contraintes de fabrication qui l'accompagnent. Le tour a été mené par Insight Partners, avec la participation de Chalfen Ventures, Rock Yard Ventures et Garage Capital. Avec un pre-seed de 1,5 million de dollars, la société basée à San Mateo a levé 8,9 millions de dollars au total.

Son premier produit est une autocomplétion pour les logiciels de CAO. Pendant que l'ingénieur dessine dans sa CAO, Hestus propose l'action suivante (une contrainte, une cote, une géométrie) et l'ingénieur l'accepte d'une seule touche. Nous avons échangé avec Sohrab Haghighat, cofondateur et CEO, sur trois sujets : pourquoi le vrai goulot d'étranglement du boom de la physical AI se trouve selon lui sur l'écran de l'ingénieur, pourquoi il ne construit pas sur un grand modèle de langage, et comment 5 000 ingénieurs ont adopté le produit grâce à une croissance purement organique.

Hestus en bref

  • Entreprise : Hestus, Inc.
  • Siège : San Mateo, Californie, États-Unis
  • Fondateurs : Sohrab Haghighat (CEO) et Kevin Chu (CTO)
  • Accélérateur : Y Combinator, batch été 2024
  • Activité : copilote IA intégré aux logiciels de CAO, qui lit l'intention de conception de l'ingénieur et propose les étapes suivantes
  • Produit : Sketch Helper, disponible pour Autodesk Fusion sur Mac et Windows ; intégration SolidWorks en bêta privée
  • Utilisateurs : plus de 5 000 ingénieurs
  • Dernier tour : seed de 7,4 M$, annoncé le 2 octobre 2026
  • Investisseur principal : Insight Partners
  • Autres investisseurs : Chalfen Ventures, Rock Yard Ventures, Garage Capital
  • Pre-seed : 1,5 M$ mené par Liquid2 Ventures et Rock Yard Ventures, avec Y Combinator, Kyle Vogt et Eric Migicovsky
  • Total levé : 8,9 M$

Les fondateurs : des ingénieurs hardware qui ont fait les clics eux-mêmes

Sohrab Haghighat et Kevin Chu faisaient partie des dix premiers employés de Cruise, la société de voitures autonomes. Sohrab Haghighat a ensuite dirigé SpaceRyde, une startup de lancement spatial, tandis que Kevin Chu dirigeait l'ingénierie chez Mendaera, une entreprise de dispositifs médicaux. Tous deux ont passé leur carrière à construire des produits physiques, et tous deux savent où partent les heures.

« Kevin et moi venons du monde du hardware. Nous sommes des ingénieurs hardware, explique Sohrab Haghighat. Nous avons souffert de tous ces clics manuels, et de tous les détails qu'il faut jongler dans sa tête. Notre objectif ultime, c'est de faciliter la vie des ingénieurs. »

Ce parcours lui sert aussi de filtre pour décider quoi construire. « Je me pose toujours la question : pendant mes études, à mon premier poste, ou quand je dirigeais SpaceRyde, est-ce qu'un tel outil m'aurait aidé ? Si la réponse est oui, nous devons le construire. Si c'est non, nous ne devons pas le faire. »

Le goulot d'étranglement est sur l'écran de l'ingénieur

Sohrab Haghighat aborde le problème sous deux angles. Le premier, c'est la physical AI. Si la robotique continue de progresser à ce rythme, il anticipe une explosion du nombre de robots à fabriquer dans le monde. L'essentiel de l'attention, et de l'argent, va à l'IA qui permet à ces robots de comprendre le monde. « Mais avant de pouvoir construire un produit physique, il faut le concevoir », rappelle-t-il. Dans les cinq prochaines années, la demande en biens physiques va augmenter sans que la capacité à les concevoir suive.

Le second angle, c'est l'outil lui-même. Chaque objet physique, jusqu'à la bouteille d'eau posée sur votre bureau, a d'abord été un design numérique dans un logiciel de CAO. « La CAO que nous utilisons n'a pas vraiment changé depuis quarante ans. Ce n'est pas forcément une mauvaise chose, nuance-t-il. Le problème, c'est que la CAO ne comprend pas la seule chose qu'elle devrait comprendre : la fabrication. »

Chaque design passe donc par des séries d'itérations avant de pouvoir être fabriqué. « Il y a un fossé énorme entre un joli modèle 3D et un modèle 3D prêt à être fabriqué », explique-t-il. Et c'est ce fossé, selon lui, que le débat sur la réindustrialisation ne voit pas. « Tout le monde pense que le vrai goulot d'étranglement, c'est la capacité de production. On essaie de construire plus d'usines, de rapatrier la production aux États-Unis, en Europe ou au Canada. Mais le vrai goulot d'étranglement, c'est le passage du concept dans la tête du designer à un design fini et fabricable que l'on peut transmettre à l'usine. Et cela oblige les ingénieurs à jongler avec énormément de paramètres dans leur tête et à les implémenter manuellement dans la CAO. »

L'entreprise chiffre le phénomène : sur l'ensemble du travail de conception, seuls 20 à 30 % relèvent du travail créatif. Le reste consiste à documenter ce design dans la CAO, et c'est précisément la partie qu'Hestus veut automatiser.

L'autocomplétion aujourd'hui, l'intelligence mécanique demain

Sketch Helper lit l'esquisse au fur et à mesure que l'ingénieur la dessine. Il trace un rectangle, l'outil propose les deux axes médians ; il place un cercle dans un quadrant, l'outil peut proposer l'ensemble symétrique avec les contraintes de symétrie déjà appliquées. Les suggestions s'affichent en surimpression rouge, l'ingénieur les fait défiler, et une touche suffit pour valider. L'entreprise annonce un travail 2,5 fois plus rapide avec quatre fois moins de clics.

Quand j'ai comparé cela à ce qui s'est passé dans le logiciel, où les outils d'IA ont progressivement appris les contraintes d'un vrai code de production, Sohrab Haghighat a validé la trajectoire et s'en est servi pour décrire sa roadmap. « Les agents de code ont commencé par de tout petits pas : compléter une ligne, suggérer un nom de variable. Puis ils se sont améliorés : ils savaient écrire une boucle. Puis une fonction. Puis un logiciel entier, mais en oubliant les contrôles de sécurité et en faisant des erreurs grossières. Et maintenant, ils s'améliorent encore, détaille-t-il. Nous voulons passer par les mêmes étapes. »

Aujourd'hui, Hestus anticipe une étape. Ensuite, l'outil devra en proposer dix. Puis gérer une pièce complète ou un ensemble de pièces, avant d'intégrer l'optimisation des coûts de fabrication : « Comment faire ce produit, toujours aussi bon et fonctionnel, mais moins cher, pour pouvoir le fabriquer en série ? »

Chaque étape exige un modèle qui comprend le monde physique. « Qu'est-ce que ça veut dire, pour deux engrenages, de bien s'engrener ? Pour une tolérance, d'être lâche ou d'exiger un ajustement serré ? C'est ça, au fond, ce que nous voulons construire, ce que nous appelons l'intelligence mécanique. »

Pourquoi Hestus ne construit pas sur un LLM

C'est là que Sohrab Haghighat s'écarte de l'analogie avec le logiciel. « Ce qui alimente la révolution du développement logiciel, ce sont les LLM. Mais nous sommes convaincus que les grands modèles de langage ne sont pas forcément la meilleure architecture pour résoudre le problème de la conception physique. »

Plutôt que d'affiner un modèle de langage pour qu'il raisonne sur la géométrie, Hestus conçoit sa propre architecture de zéro. Il s'appuie sur des précédents. « Personne n'utilise un LLM pour générer les pixels d'une image ou d'un film. La génération d'images et de vidéos repose principalement sur des modèles de diffusion. C'est une architecture différente. » Un modèle conçu spécifiquement pour le raisonnement spatial peut, selon lui, être bien plus compact et plus performant pour raisonner sur les contraintes physiques et de fabrication. « Nous n'essayons pas de résoudre le problème de l'AGI. Nous essayons seulement de résoudre celui de l'intelligence mécanique. »

Un modèle plus petit et spécialisé a aussi un argument commercial. « L'usage de l'IA explose. Tout le monde se demande : est-ce que j'ai le budget ? Combien de tokens je peux me permettre ? Si vous arrivez avec un modèle plus efficace dans sa consommation de tokens, il sera forcément bien accueilli par ses utilisateurs. »

Le texte pour les spécifications, la souris pour les formes

Le site d'Hestus se moque du long prompt textuel qu'un ingénieur devrait écrire pour décrire une simple esquisse à un chatbot. Sohrab Haghighat précise pourtant que l'entreprise n'est pas contre le texte. Le texte a un rôle : porter les spécifications. Une équipe commerciale revient de chez les clients avec les exigences du prochain produit. Des régulateurs comme la FAA, la FDA ou la NHTSA y ajoutent leurs propres normes. « La meilleure façon de communiquer ça à une IA, c'est le texte, en téléversant le document. »

Les formes, c'est une autre affaire. « Si je demande à un ingénieur mécanique de décrire une forme avec des mots, c'est le monde à l'envers. "Le cercle qui est à droite et au-dessus de cette ligne, pas celui de trois millimètres mais celui de quatre, déplace-le de dix millimètres." Personne ne fait ça. » Souvent, la pièce suivante doit simplement s'adapter à la géométrie déjà présente à l'écran. « Il suffit de charger la CAO, et une IA correctement entraînée voit le motif. Je n'ai pas besoin que l'ingénieur me l'explique. Dès qu'il commence à travailler, je connais probablement ses dix prochaines étapes. Autant les lui proposer. »

À ses yeux, beaucoup de startups d'IA pour la CAO existent parce que leurs fondateurs ont vu une opportunité après le décollage des agents de code ou de l'IA juridique, et se sont demandé quelle serait la prochaine frontière. « J'affirme que la majorité des dirigeants de ces entreprises n'ont jamais passé une seule journée à concevoir un produit physique, ni mis les pieds dans un atelier d'usinage. » L'approche d'Hestus consiste à tirer les leçons de la progression des agents de code et à reconstruire chaque étape pour la façon dont travaillent les ingénieurs mécaniques. « Demander à un ingénieur mécanique de travailler comme un ingénieur logiciel, ou l'inverse, je pense que c'est la mauvaise approche. »

Go-to-market : faire de l'ingénieur le champion

Hestus a atteint 5 000 ingénieurs sans cibler d'entreprises. « Tout s'est fait en bottom-up, en passant par notre réseau, en mettant le produit entre les mains de chaque ingénieur et en le laissant en devenir le champion. C'était une croissance purement organique. »

Le modèle, là encore, c'est la façon dont les outils de code ont grandi. « Ce n'est pas une grande entreprise qui les a adoptés. C'est chaque ingénieur, individuellement, qui les a utilisés pour ses projets perso, les a présentés à ses collègues, et peu à peu ils se sont frayé un chemin dans les petites entreprises d'abord, puis les moyennes, puis les grandes organisations. Nous pensons que c'est le chemin à suivre. »

Sohrab Haghighat a appris cette leçon côté acheteur, quand il dirigeait SpaceRyde. Un autre fondateur lui présente un outil pour les workflows d'ingénierie ; l'outil lui plaît, il demande à son équipe de l'essayer. Quelques semaines plus tard, l'ingénieur le plus franc de l'équipe vient le voir : pourquoi les oblige-t-il à l'utiliser ? L'équipe avait déjà construit ces briques en interne six mois plus tôt. « C'est là que j'ai compris que la demande pour un outil d'ingénierie doit venir de l'équipe d'ingénierie. Elle ne doit pas venir de la direction. »

À partir de là, la logique s'inverse. Ce sont les ingénieurs qui viennent lui demander des logiciels, toujours avec le même argument : tu te souviens de ce jalon où on a perdu tant de temps ? Cet outil résoudrait le même problème cinq fois plus vite. Ils se mettent d'accord sur un essai et un critère de succès, et si ça fonctionne, ils prennent un abonnement court. « C'est comme ça que ça doit se passer. L'ingénieur doit être le champion de l'outil. Le manager ne doit pas l'imposer d'en haut. »

Quand je lui ai suggéré que cela prépare aussi la future vente grands comptes, avec des centaines d'ingénieurs d'une entreprise utilisant déjà le produit au moment où quelqu'un parle à l'acheteur économique, il a acquiescé. Mais pour l'instant, la priorité reste les utilisateurs. « Si je veux que l'ingénieur soit le champion de mon outil, je dois me mettre à son niveau et lui demander : qu'est-ce qui ne fonctionne pas pour toi ? Quels sont les trois, cinq problèmes qui t'empêchent de faire le travail pour lequel tu as étudié et que tu aimes faire ? » Hestus ne résout pas toujours le problème, admet-il. « Clairement pas à 100 %. Mais quand ils voient qu'on a fait bouger les lignes, qu'on a pris la peine d'écouter et de développer quelque chose pour eux, on construit une relation avec son utilisateur. Ce feedback, une fois qu'on le travaille, c'est l'ingrédient le plus important du succès. »

Concrètement, l'entreprise veut être connue de chaque ingénieur mécanique : des étudiants en génie mécanique, des ingénieurs en startup comme de ceux des grands groupes. La prochaine étape de distribution, c'est SolidWorks : l'intégration est en bêta privée, disponible sur demande, et sa sortie publique double à peu près le nombre d'ingénieurs qu'Hestus peut toucher. D'autres plateformes de CAO suivront.

Pour autant, Sohrab Haghighat voit le produit comme le principal canal de croissance. « Chaque nouvel utilisateur a ses exigences, ses cas d'usage. Nous en tirons des enseignements et construisons de nouvelles fonctionnalités, qui, on l'espère, seront utiles à d'autres, ce qui attire de nouveaux utilisateurs. Chaque jour, nous nous demandons : quelle fonctionnalité nos ingénieurs vont-ils le plus apprécier ? »

À quoi vont servir les 7,4 M$

La plus grande partie du tour sera consacrée au recrutement, sur deux fronts : des ingénieurs logiciels seniors et staff, et des chercheurs en machine learning. « Nous avons une grande vision et un grand rêve à réaliser, mais nous ne pouvons pas tout faire seuls », souligne Sohrab Haghighat. Les lecteurs qui ont ce profil trouveront les postes ouverts sur la page carrières d'Hestus.

Son ambition à long terme dépasse le gain de clics. « Chaque corps est différent. En vieillissant, nous aurons peut-être besoin de prothèses ou d'aides techniques, et ce qui convient à mon corps ne conviendra pas forcément à celui de quelqu'un d'autre. Et si chaque dispositif pouvait être conçu sur mesure pour chaque personne ? » La même logique vaut pour un avion conçu en deux fois moins de temps et toujours plus économe en carburant, une nouvelle voiture, ou des robots médicaux qui demandent des décennies à concevoir et à construire. « Et si nous pouvions réduire le temps de mise sur le marché de ces produits ? »

Les leçons GTM pour les fondateurs deeptech

  1. Nommer le goulot d'étranglement que les autres ne voient pas. Hestus se positionne contre l'idée répandue que les usines sont la contrainte, et situe le problème entre le concept et le design fabricable.
  2. Pour un outil d'ingénierie, la demande vient de l'ingénieur. Un outil imposé par la direction est rejeté ; un outil demandé par un ingénieur obtient un essai, un critère de succès et un budget.
  3. Suivre le chemin d'adoption des outils pour développeurs. D'abord les utilisateurs individuels, puis leurs collègues, puis les petites entreprises, puis les grandes organisations, les contrats grands comptes arrivant une fois l'usage installé.
  4. Adapter l'interface au travail. Le texte pour les spécifications et les exigences, la manipulation directe pour les formes. Une fenêtre de chat n'est pas la réponse par défaut pour tous les métiers.
  5. S'installer dans les outils que les utilisateurs ont déjà. Une intégration directe avec Fusion et SolidWorks, c'est rien de nouveau à apprendre et aucun fichier à déplacer, et chaque nouvelle intégration ouvre une nouvelle base d'utilisateurs.
  6. Écouter, même quand on ne peut pas tout résoudre. Demander aux utilisateurs leurs principaux problèmes, et revenir avec des progrès, construit la relation qui entretient la croissance product-led.