Shanea Leven, fondatrice et PDG d’Empromptu AI – Série d’entretiens

Shanea Leven, fondatrice et PDG d’Empromptu AI, est une veterane du leadership de produits avec une expérience approfondie dans la construction de plateformes de développement et de produits alimentés par l’IA au sein de grandes entreprises technologiques. Avant de lancer Empromptu en 2025, elle a fondé CodeSee, une plateforme de développement d’IA qui aide les équipes à visualiser et à comprendre des bases de code complexes, qui a été acquise par GitKraken en 2024. Plus tôt dans sa carrière, elle a occupé des postes de leadership de produits seniors au sein de sociétés telles que Docker, Cloudflare, eBay et Google (GOOGL ), où elle a travaillé sur des initiatives allant des API de paiement de Google Assistant à des programmes de formation de développeurs utilisés par des centaines de milliers d’apprenants.

Empromptu AI est une plateforme d’entreprise conçue pour aider les organisations à construire et à déployer des applications d’IA intégrées plus facilement. La plateforme combine le développement d’applications, l’intégration de données, la gouvernance, les évaluations, la mémoire et l’orchestration de modèles en un seul environnement, permettant aux entreprises de passer d’une expérimentation rapide d’IA à des systèmes de production de qualité avec les contrôles et la fiabilité nécessaires pour une utilisation d’entreprise.

Vous avez passé plus de 15 ans à construire des plateformes de développement au sein de sociétés comme Google, eBay, Cloudflare et Docker avant de fonder CodeSee, qui a été acquise par GitKraken, et maintenant en tant que PDG d’Empromptu AI. Comment ces expériences ont-elles façonné votre perspective sur la raison pour laquelle de nombreux outils d’IA échouent une fois qu’ils quittent le stade de la démonstration, et quel problème spécifique étiez-vous déterminé à résoudre lorsque vous avez fondé Empromptu ?

L’une des choses que l’on apprend en construisant des plateformes de développement, c’est que les problèmes les plus difficiles ne sont jamais ceux de la démonstration. La démonstration fonctionne toujours. Le véritable test est ce qui se passe lorsque des milliers de développeurs utilisent le système, lorsque les données sont désordonnées, lorsque les intégrations sont cassées et lorsque des entreprises réelles en dépendent.

Chez Google, Cloudflare, Docker et eBay, j’ai passé des années à travailler sur des plateformes qui devaient fonctionner à l’échelle mondiale. Ces environnements vous enseignent rapidement quelque chose : la fiabilité, la gouvernance et l’observabilité ne sont pas des fonctionnalités que l’on ajoute plus tard. Ce sont l’architecture.

Lorsque j’ai commencé à construire des applications d’IA, les modèles étaient terribles et, à mesure qu’ils commençaient à s’améliorer, j’ai remarqué que l’industrie répétait la même erreur que nous avions vue dans les précédentes vagues de logiciels. Dans les outils de développement, il y a un concept qui semblait avoir été oublié. À quelle vitesse pouvez-vous arriver à « bonjour le monde » ? Aujourd’hui, la version générative de « bonjour le monde » est un prototype de SaaS fonctionnel. Mais nous ne codons pas seulement des applications SaaS ; nous codons des applications d’IA entières. Un IA qui construit un IA nécessite d’autres systèmes pour mettre cet IA en production.

Vous pouvez générer une application d’IA fonctionnelle ou une fonction rapidement, ce qui est excitant et vraiment utile. Mais les systèmes prédominants manquent encore des infrastructures nécessaires pour les environnements de production. Des choses comme les pipelines de données structurées, les cadres d’évaluation, les contrôles de gouvernance, la surveillance et la gestion du contexte à long terme ont été manquées, mais nous les avons intégrées tout en conservant les parties incroyables du codage d’IA.

Lorsque mon co-fondateur et moi avons fondé Empromptu, le problème que nous voulions résoudre était simple : comment rendre les applications d’IA prêtes pour la production dès le départ ?

Au lieu de traiter la gouvernance, la préparation des données, l’évaluation et l’optimisation comme des outils ou des processus distincts, nous les avons intégrés directement dans la plateforme. L’idée est que les équipes devraient être en mesure de construire des applications d’IA rapidement, mais avec la même fiabilité, la même qualité et le même contrôle qu’elles attendent des systèmes logiciels d’entreprise.

Vous avez été ouverte sur le fossé entre les démonstrations d’IA impressionnantes et les systèmes prêts pour la production. De votre point de vue, quels sont les erreurs architecturales les plus courantes que les équipes commettent lorsqu’elles tentent de transformer un prototype d’IA en un produit fiable utilisé par de vrais clients ?

L’erreur la plus courante que les équipes commettent est de supposer que le modèle est le produit.

Dans les prototypes précoces, le modèle effectue la majeure partie du travail visible. Vous le sollicitez, il produit une réponse, et si la réponse semble bonne, le système semble fonctionner. Cela crée l’illusion que l’amélioration du modèle est le principal défi.

Mais dans les systèmes de production, le modèle n’est qu’un composant d’une architecture beaucoup plus large.

La première erreur est de traiter les données comme une après-pensée. Dans les prototypes, les équipes testent souvent avec de petits ensembles de données propres. Une fois que le système se connecte à des données opérationnelles réelles, les choses changent rapidement. Les données arrivent incomplètes, incohérentes, dupliquées ou dans des formats inattendus. Sans un pipeline de données structuré pour normaliser et valider les entrées, le système devient peu fiable, quelle que soit la qualité du modèle.

La deuxième erreur est l’absence de cadres d’évaluation. De nombreuses équipes lancent des fonctionnalités d’IA sans définir ce que « bon » signifie réellement. Ils peuvent vérifier manuellement les sorties pendant le développement, mais ils ne construisent pas de pipelines d’évaluation automatisés qui mesurent continuellement la précision, la dérive et les cas de bord une fois que le système est en direct. Sans ces garde-fous, les défaillances sont souvent découvertes par les clients plutôt que par les ingénieurs.

Un troisième problème est le manque de mécanismes de gouvernance et de contrôle. Les systèmes d’IA sont probabilistes, ce qui signifie qu’ils peuvent se comporter différemment dans des conditions légèrement différentes. Dans des environnements réglementés ou à enjeu élevé, cette imprévisibilité doit être contrainte par des politiques déterministes, des flux de travail d’approbation et des journaux d’audit qui capturent la manière dont les décisions ont été prises.

Cela se résume à ceci : les systèmes d’IA de production ne sont pas seulement des modèles. Ce sont des systèmes opérationnels.

Les entreprises qui réussissent avec l’IA aujourd’hui sont celles qui traitent les pipelines de données, l’évaluation, la gouvernance et la surveillance comme des infrastructures de base, et non comme des ajouts optionnels.

De nombreux plateformes de codage d’IA promettent que n’importe qui peut construire une application en utilisant des invites simples. Pourquoi ces outils fonctionnent-ils souvent bien pour les démonstrations mais luttent-ils une fois que les entreprises tentent de les déployer dans des environnements de production réels ?

De nombreuses plateformes fonctionnent bien pour les démonstrations car elles sont optimisées pour le moment de la création, et non pour le cycle de vie d’un système réel.

Mais il y a une différence fondamentale entre utiliser l’IA pour générer une page de destination et utiliser l’IA pour construire une application d’IA.

Une page de destination est principalement un logiciel statique. Une fois qu’elle est rendue correctement, le travail est largement terminé. Le système n’a pas à prendre des décisions probabilistes, à ingérer des données en constante évolution ou à s’adapter à un comportement d’utilisateur imprévisible.

Les applications d’IA sont complètement différentes. Ce sont des systèmes dynamiques qui reposent sur des pipelines de données, le comportement des modèles, les cadres d’évaluation et une surveillance continue. L’application doit gérer le contexte, détecter les sorties dérivées, gérer les cas de bord et fonctionner en toute sécurité lorsque le modèle rencontre des situations qu’il n’a pas vues auparavant.

La plupart des outils de codage basés sur des invites ne traitent pas de ces couches car ils sont conçus pour obtenir quelque chose de fonctionnel rapidement. Ils génèrent du code qui produit un résultat visible, ce qui est parfait pour un environnement de démonstration. Mais les systèmes de production nécessitent un ensemble de capacités beaucoup plus large : traitement de données structurées, contrôles de gouvernance, pipelines d’évaluation, observabilité et mécanismes pour mettre à jour le comportement en toute sécurité au fil du temps.

Donc, lorsque les entreprises tentent de déployer ces systèmes dans des environnements réels, le fossé devient évident. Le prototype fonctionnait parce que l’environnement était contrôlé. La production est désordonnée.

Empromptu se concentre sur la transformation de logiciels existants en systèmes d’IA natifs plutôt que de forcer les entreprises à tout reconstruire à partir de zéro. Cette transformation implique-t-elle réellement au niveau de l’infrastructure et du produit ?

Au niveau du produit, chaque application est entièrement autonome et conteneurisée. Nous créons tout ce dont vous avez besoin, des interfaces utilisateur, des back-ends, des bases de données, des modèles, des évaluations, des règles et tout est super flexible en fonction des besoins de l’entreprise.

Nous avons plusieurs options pour les applications d’IA :

« Headless » pour que si un client a déjà une interface utilisateur, nous puissions la connecter à notre système et renvoyer les données.

Entièrement conteneurisé pour qu’ils puissent être déployés sur notre infrastructure ou au sein de l’infrastructure du client, donc ils sont par défaut sur site.

Ou nous pouvons simplement les générer et les déployer directement dans le cloud pour l’option la plus pratique.

Tout code qu’ils ont, nous pouvons l’importer directement dans notre système et le rendre agentifié s’il ne l’est pas déjà. Par exemple, nous voyons cela avec de nombreux clients qui ont tenté de construire leurs applications sur des plateformes populaires comme Lovable, Replit, Bolt ou Base44. Souvent, ils ne fonctionnent pas. Mais les clients ont déjà investi beaucoup de temps et d’énergie et de crédits dans cette application, donc nous l’ingérons, la réécrivons, faisons fonctionner l’IA.

Et nous pouvons le faire parce que nous avons plusieurs technologies propriétaires, telles que :

• Moteur de contexte adaptatif pour gérer le contexte
• Mémoire infinie pour ingérer des applications de code à longue durée de vie
• Modèles de données personnalisés et pipelines de données dorés pour nous assurer que nous pouvons gérer tout nettoyage de données et étiquetage synthétique requis

Votre plateforme met l’accent sur le contexte, l’évaluation, la gouvernance et les données structurées comme composants essentiels des systèmes d’IA. Pourquoi ces éléments sont-ils si souvent négligés lorsque les équipes se précipitent pour ajouter des fonctionnalités d’IA à leurs produits ?

Parce que c’est difficile à faire ! Mon co-fondateur, le Dr Sean Robinson, dirige notre laboratoire de recherche, et il est un astrophysicien computationnel qui a inventé plusieurs technologies inspirées par mes idées folles, mais aussi par les besoins de nos clients et par la direction du marché. Notre expérience combinée dans la construction de nombreuses applications agentes, le lancement de satellites dans l’espace et la construction au sein des plus grandes entreprises technologiques du monde nous donne des idées qui nous aident à résoudre des problèmes compliqués mieux que les autres.

Vous travaillez avec de nombreux fondateurs qui n’ont jamais écrit de code auparavant. Quelles sont les plus grandes idées fausses que les fondateurs non techniques ont lorsqu’ils tentent de construire des applications d’IA pour la première fois ?

Je pense qu’il y a deux grandes idées fausses :

La première est que l’IA est magique. L’IA n’est pas magique. C’est juste une bonne ingénierie. Et éventuellement, vous atteignez une limite sur ce que vous pouvez faire sur ces plateformes sans un véritable ingénieur.

La deuxième est qu’ils ont d’excellentes compétences en gestion de produits techniques. J’ai une expérience en gestion de produits techniques et la compétence pour traduire une vision, parfois une vision très large, en petits morceaux pouvant être expédiés avec la bonne spécification technique pour articuler exactement ce que vous voulez. C’est en fait une compétence très difficile qui prend du temps.

Par exemple, disons que vous construisez une application qui télécharge un PDF et enregistre ce PDF pour que vous puissiez le revoir plus tard. C’est un concept appelé persistence. Ce PDF est encodé en code et enregistré dans une base de données.

Mais si vous ne saviez pas que c’était appelé persistence, comment seriez-vous en mesure de le faire ? Assurez-vous que ces données persistent. Le choix de mots techniques est comme parler une autre langue. Il y a une différence entre écrire en langage naturel et écrire en langage technique.

De nombreuses startups supposent que la solution pour construire des produits d’IA est simplement d’embaucher plus d’ingénieurs. Pourquoi pensez-vous que cette approche échoue souvent, et à quoi les fondateurs devraient-ils réfléchir à la place lors de la construction de produits alimentés par l’IA ?

Embaucher plus d’ingénieurs est parfois la bonne réponse. Si vous construisez un produit profondément technique ou que vous travaillez à la frontière de la recherche de modèles, vous avez absolument besoin de solides équipes d’ingénieurs. Il n’y a pas de substitut à de bons ingénieurs lorsqu’il s’agit de résoudre des problèmes difficiles.

Mais l’erreur que de nombreuses startups commettent est de supposer que plus d’ingénieurs résolvent automatiquement le défi de construire un produit d’IA.

En réalité, les problèmes les plus difficiles dans les produits d’IA ne sont souvent pas des problèmes purement d’ingénierie. Ce sont des problèmes de systèmes, tout comme les autres problèmes d’ingénierie. Les ingénieurs sont spécifiquement formés pour penser en termes de systèmes. Mais le développement génératif est différent du développement déterministe. Beaucoup d’entre nous ont fait ce changement lorsque nous sommes passés de la programmation orientée objet à la programmation fonctionnelle. S’agit-il de programmation ? Oui, absolument, mais s’agit-il d’une façon de penser différente ? Oui, bien sûr.

Les applications d’IA se situent à l’intersection des données, de la conception de produits, des flux de travail opérationnels et du comportement des modèles. Vous pouvez embaucher une équipe d’ingénieurs incroyable, mais si les pipelines de données sont peu fiables, les critères d’évaluation sont flous ou le système manque de gouvernance et de surveillance, le produit sera toujours en difficulté une fois qu’il atteint les utilisateurs réels.

Un autre problème est que de nombreuses équipes sautent directement dans la construction avant d’avoir défini comment le système d’IA se comportera en production. Des questions comme celles de savoir comment le système sera évalué, comment les cas de bord seront gérés, comment les décisions seront consignées et comment les modèles seront mis à jour en toute sécurité au fil du temps sont souvent abordées plus tard. À ce stade, l’architecture est déjà difficile à modifier.

À quoi les fondateurs devraient-ils vraiment réfléchir, c’est au modèle opérationnel de leur système d’IA.

Qui possède le pipeline de données ?

Comment la performance du modèle est-elle mesurée en continu, et non seulement pendant le développement ?

Que se passe-t-il lorsque le système rencontre une situation qu’il n’a pas vue auparavant ?

Comment mettre à jour le comportement en toute sécurité sans casser les flux de travail en aval ?

Parfois, résoudre ces problèmes signifie embaucher plus d’ingénieurs. Mais cela peut également signifier choisir la bonne infrastructure, définir de solides contraintes de produits et construire des systèmes qui permettent à de petites équipes de fonctionner de manière fiable à grande échelle.

Les entreprises qui réussissent avec l’IA aujourd’hui ne sont pas nécessairement celles qui ont les plus grandes équipes d’ingénieurs. Ce sont celles qui traitent l’IA comme un système à long terme qui nécessite de la discipline de données, de l’évaluation, de la gouvernance et de l’amélioration continue intégrées dès le départ.

Vous avez soutenu que certains des modèles commerciaux actuels des outils de développement d’IA ne sont pas alignés sur la construction de produits durables. Quels sont les incitateurs dans l’écosystème actuel des outils d’IA qui, selon vous, orientent les entreprises dans la mauvaise direction ?

L’un des plus grands déséquilibres d’incitation actuellement est que de nombreux outils de développement d’IA sont optimisés pour les indicateurs de croissance plutôt que pour la durabilité du produit.

Beaucoup de sociétés dans cet espace sont récompensées pour la rapidité avec laquelle les utilisateurs peuvent créer quelque chose d’impressionnant. Si un outil peut générer une application fonctionnelle, une fonctionnalité ou une démonstration en quelques minutes, cela stimule les inscriptions, le partage sur les réseaux sociaux et l’enthousiasme des investisseurs. Du point de vue de l’adoption du produit, cela a du sens.

Mais ces incitateurs s’arrêtent souvent au moment de la création.

Le travail le plus difficile dans les logiciels d’IA se produit après ce point. C’est là que la confiance est construite. Lorsque vous pouvez vous fier à la qualité. Que l’utilisateur veut revenir encore et encore sans la frustration de l’IA due à de mauvaises sorties. Besoin de fournir de bonnes réponses même face à l’ignorance ou à la malveillance humaine.

Un autre problème est que de nombreux outils sont optimisés pour la génération de code plutôt que pour la conception de systèmes. Générer du code rapidement est utile, mais construire un produit d’IA implique plus que produire du code. Cela nécessite de définir la manière dont le système gère le contexte, comment les décisions sont évaluées, comment les défaillances sont gérées et comment le comportement évolue en toute sécurité au fil du temps.

Les entreprises qui alignent leurs incitateurs sur l’aide aux clients pour exécuter des systèmes d’IA de manière fiable, et non seulement les construire rapidement, sont celles qui créeront de la valeur durable dans cet écosystème.

Certains de vos clients comprennent des entrepreneurs qui construisent des produits très spécifiques, tels que des outils de santé spécialisés ou des entreprises axées sur la durabilité, souvent sans équipes d’ingénieurs traditionnelles. Quels sont les modèles que vous avez observés parmi les fondateurs qui réussissent à transformer ces idées en produits d’IA fonctionnels ?

L’un des modèles les plus intéressants que nous voyons est que les fondateurs qui réussissent ne sont pas nécessairement les plus techniques. Ce sont ceux qui comprennent extrêmement bien le problème qu’ils résolvent.

Beaucoup des entrepreneurs utilisant Empromptu sont des experts dans leur domaine. Ils peuvent provenir des soins de santé, de la finance, de la durabilité ou d’une autre industrie spécialisée. Ce qu’ils apportent, c’est une connaissance approfondie des flux de travail, des réglementations et des décisions qui existent dans cet environnement. Ce contexte est incroyablement précieux lors de la conception d’un produit d’IA car il définit ce que le système doit réellement faire.

Les fondateurs qui réussissent tendent à aborder l’IA moins comme une expérience technologique et plus comme un système de produit. Ils commencent par poser des questions très concrètes. Quelles décisions l’IA doit-elle aider les utilisateurs à prendre ? Quelles sources de données doit-elle accéder ? Qu’est-ce qu’une réponse correcte ressemble à dans ce domaine ? Quels garde-fous doivent exister pour que le système se comporte de manière responsable ?

Un autre modèle est qu’ils réfléchissent soigneusement à la structure. Les équipes qui réussissent réalisent rapidement que les sorties d’IA ne sont que aussi bonnes que le contexte et les données qui les alimentent. Ils investissent du temps à l’avance pour définir des pipelines de données, organiser les sources de connaissances et créer des critères d’évaluation clairs pour ce que « bon » signifie.

Nous voyons également les fondateurs réussis adopter la collaboration humaine-IA au lieu d’essayer d’automatiser tout de suite. Ils conçoivent des flux de travail dans lesquels l’IA gère l’analyse répétitive ou la synthèse des données, tandis que les humains restent responsables du jugement et des décisions finales. Cet équilibre rend les systèmes beaucoup plus fiables, en particulier dans des domaines tels que les soins de santé ou la finance.

De bien des manières, le plus grand changement est de mentalité. Les fondateurs qui réussissent ne pensent pas à l’IA comme une fonctionnalité qu’ils ajoutent. Ils pensent à l’IA comme une nouvelle couche opérationnelle pour la façon dont leur produit fonctionne.

À mesure que les systèmes d’IA sont de plus en plus intégrés dans les opérations commerciales de base, quels seront les capacités qui définiront la prochaine génération de plateformes d’applications d’IA ?

Je sais que c’est fou et que je peux dire quelque chose de sacrilège, mais les gens pourront vibe-coder leurs propres modèles personnalisés. Quelque chose que notre laboratoire de recherche appelle des modèles d’expert nano aidera à contrôler les coûts.

Je vous remercie pour cette grande interview. Les lecteurs qui souhaitent en savoir plus peuvent visiter Empromptu AI.