Faut-il créer votre propre agent de démo IA en vibe coding ?

Pouvez-vous créer votre propre agent de démo IA en vibe coding ? Vous pouvez en construire un qui fonctionne en un week-end. Le mettre devant de vrais acheteurs, sur votre vrai produit, tous les jours, est un tout autre projet. Et c'est de ce second projet que dépend votre pipeline.

Voici ce que ce second projet implique, et la difficulté de chaque partie :

Enjeu	Ce que ça demande	Difficulté
Piloter votre produit en direct	Connexions, codes d'authentification, protections anti-bots et parcours qui résistent aux changements d'interface	Très difficile
Latence	Écouter, réfléchir, parler et cliquer en une seconde environ	Très difficile
Technologies vocales	Une voix naturelle, les tours de parole, les interruptions, les accents et le bruit	Difficile
Sandboxes	Des données de démo réalistes, réinitialisées après chaque session et synchronisées avec votre produit	Difficile
Prompting et garde-fous	Tenir le bon discours, sans jamais inventer de prix, de fonctionnalités ni d'arguments de sécurité	Difficile
Évaluations	Noter les conversations et détecter les régressions après chaque changement de prompt ou de modèle	Difficile
Transmission au CRM et au pipeline	Capture des leads, enrichissement, synchronisation avec HubSpot ou Salesforce et relances	Moyen
Maintenance	Revérifier tout ce qui précède à chaque nouvelle version du produit et à chaque changement de modèle	Jamais terminé

C'est une phrase que nous entendons souvent chez les équipes qui évaluent Karumi : « quelqu'un chez nous pourrait faire ça en vibe coding ». Le réflexe se comprend. Les agents de code sont désormais très performants. Branchez un LLM à un navigateur headless, ajoutez une API vocale, pointez le tout vers votre application, et dimanche soir, quelque chose parle et clique dans votre produit.

Nous avons aussi vu comment l'histoire se termine. Des équipes qui avaient construit leur propre agent sont revenues vers nous après avoir mesuré à quel point le système est difficile et coûteux à mettre en place et à faire tourner. Cet article décrit ce qu'elles ont rencontré une fois le prototype fonctionnel.

Que réussit un agent de démo créé en vibe coding ?

La boucle de base est vraiment simple aujourd'hui. Un LLM sait lire une page, décider où cliquer et expliquer ce qu'il voit. Une API vocale peut le faire parler. Un agent de code vous monte l'ensemble en quelques heures.

C'est suffisant pour une démo interne. Pas pour un acheteur, car un prototype n'a besoin de fonctionner qu'une fois, devant quelqu'un qui veut que ça marche.

	Prototype du week-end	Agent face aux acheteurs
Public	Votre équipe, qui applaudit	Des acheteurs sceptiques qui partent au premier bug
État du produit	Une seule session connectée sur un ordinateur portable	Des milliers de sessions, chacune avec sa connexion, ses données et son timing
Conversation	Des questions du scénario idéal	Prix, concurrents, sécurité, « est-ce qu'il sait faire X ? »
En cas d'échec	Un éclat de rire	Un deal perdu et une mauvaise première impression
Durée de vie	Une démo	Tous les jours, à chaque nouvelle version
Responsable	La personne qui l'a codé samedi	Il en faut un, en permanence

L'écart entre ces deux colonnes, c'est le vrai projet. Et une démo est l'un des rares endroits où vous ne pouvez pas vous permettre d'échouer en production : quand elle plante, elle plante devant l'acheteur que vous vouliez le plus impressionner.

Que faut-il maîtriser pour en faire tourner un ?

Un agent de démo en production ne repose pas sur une seule technologie. Il en combine au moins quatre, et chacune est une spécialité à part entière :

• Les technologies vocales. Reconnaissance vocale, synthèse vocale, tours de parole, interruptions, accents et bruit de fond. Obtenir une voix qui sonne naturelle, et qui sait quand l'acheteur a fini de parler, est un domaine en soi.
• Les sandboxes. Une copie de votre produit avec des données réalistes, réinitialisée après chaque session, synchronisée avec ce que vous livrez, et qui n'expose jamais un vrai client.
• Le prompting. Des instructions qui maintiennent l'agent sur le bon discours, centré sur votre produit et dans vos garde-fous, à travers des milliers de conversations qu'il n'a jamais vues.
• Les évaluations. Un moyen de noter les conversations et de détecter les régressions, pour savoir si un changement de prompt ou de modèle a amélioré les choses ou les a dégradées.

Vient ensuite la latence, qui touche les quatre à la fois. Dans une conversation orale, une pause de plus d'une seconde environ donne l'impression que quelque chose ne marche pas, et l'agent doit écouter, réfléchir, parler et cliquer dans un produit en direct dans ce délai. La réduire impose de streamer chaque étape, de choisir les modèles pour leur vitesse autant que pour leur qualité, et de précharger les pages avant que l'acheteur ne les demande. C'est critique, et c'est l'une des parties les plus difficiles à réussir.

Pourquoi piloter un produit en direct est-il le plus difficile ?

C'est là que passe l'essentiel de notre propre temps d'ingénierie, pas dans le chat. Montrer votre vrai produit, plutôt qu'un enregistrement, oblige à résoudre tout ceci :

• Des connexions qui résistent. SSO, écrans qui demandent d'abord l'e-mail, liens magiques, codes d'authentification et sessions qui expirent en pleine démo. L'échec ressemble souvent à un succès : l'agent se croit connecté alors qu'il est resté sur une page de connexion.
• La protection anti-bots. Cloudflare, Akamai et les outils similaires existent pour bloquer les navigateurs automatisés. Lancez un script trop souvent sur votre propre application et votre compte de démo peut être bloqué.
• Des données de démo sûres. Les acheteurs ne doivent ni voir de vraies données clients, ni casser un compte partagé. Il vous faut une sandbox qui a l'air réelle, se réinitialise proprement et ne touche jamais la production.
• Une interface qui change sans cesse. Chaque version déplace des boutons et renomme des pages. Les clics codés en dur cassent sans prévenir : il vous faut des contrôles qui repèrent un parcours cassé avant qu'un acheteur ne tombe dessus.
• La vitesse. Une démo qui attend huit secondes à chaque page donne l'impression d'être en panne. Préchargement, mise en cache et narration calée sur le chargement des pages sont chacun un chantier à part entière.
• Les interruptions. Les vrais acheteurs coupent la parole avec un « attendez, revenez en arrière ». L'agent doit s'arrêter, répondre et reprendre là où il en était.

Rien de tout cela n'apparaît dans une vidéo de prototype. Tout cela apparaît devant un acheteur.

Que faut-il pour rendre la conversation fiable ?

Un agent de démo parle au nom de votre marque. S'il invente des choses sur votre produit devant un acheteur, il fait plus de mal que pas d'agent du tout. Le garder fiable est un travail continu :

• Des réponses fondées. Il doit répondre à partir de votre documentation, de vos études de cas et de votre positionnement, et passer la main à votre équipe plutôt que d'improviser sur les prix ou la roadmap.
• Des garde-fous. Les questions sur les concurrents, les remises, le juridique ou la sécurité, ainsi que les tentatives de jailbreak, demandent toutes un traitement réfléchi.
• Une voix naturelle. Une faible latence, la gestion des interruptions et des silences, et une narration synchronisée avec ce qui s'affiche à l'écran.
• Les langues. Si vous vendez sur plusieurs marchés, chaque script, parcours et réponse doit fonctionner dans chaque langue.
• La relecture. Quelqu'un doit lire les conversations, les noter et corriger les réponses faibles chaque semaine. Sinon, la qualité dérive sans que personne ne s'en aperçoive.
• Les questions de sécurité. Votre équipe sécurité voudra savoir où vont les transcriptions et quels fournisseurs de modèles y ont accès. Il vous faut les réponses avant qu'elle ne pose la question.

L'agent n'est-il pas tout le produit ?

Non. La valeur d'un agent de démo, c'est ce qu'il apporte à votre pipeline, et les bots maison s'arrêtent généralement à la conversation. Les équipes ventes et marketing ont besoin de tout ce qui l'entoure :

• Des points d'entrée par campagne, pour que LinkedIn, les événements, votre site web et l'outbound aient chacun leur lien, leur message d'accueil et leur parcours de départ, et que vous sachiez quel canal fonctionne.
• La capture et l'enrichissement des leads : qui est le visiteur, de quelle entreprise, et s'il correspond à votre ICP.
• La transmission à vos outils : les sessions qualifiées arrivent dans HubSpot ou Salesforce avec un résumé, le bon commercial est notifié et la relance part toute seule.
• Les insights : les questions les plus posées par les acheteurs, le moment où ils décrochent et les objections qui reviennent.
• L'édition sans code, pour que le marketing et les avant-ventes modifient scripts et parcours sans ouvrir de ticket.

Chacun de ces éléments est un petit produit à part entière. Développez-les en interne, et votre bot de démo devient une plateforme interne avec sa propre roadmap.

Combien coûte vraiment un agent développé en interne ?

Le vibe coding rend la première version presque gratuite. Il ne rend pas gratuites les cent suivantes, et c'est là que se trouve le coût.

• Chaque mise à jour produit est une mise à jour de la démo. Chaque version peut déplacer un bouton, renommer une page ou modifier un parcours. Quelqu'un doit revérifier les parcours, rafraîchir la sandbox, mettre à jour les scripts et relancer les évaluations, à chaque mise en production.
• Il faut quelqu'un pour s'en occuper. Quand la personne qui l'a construit retourne sur le produit principal, ou quitte l'entreprise, le bot casse en silence. Du code généré que personne ne comprend entièrement est difficile à transmettre.
• Les briques sous-jacentes bougent sans cesse. Les fournisseurs de LLM, de voix et d'automatisation de navigateur changent de modèles, de prix et d'API tous les quelques mois. Chaque changement implique une nouvelle série de tests, et souvent une réécriture.
• Il fait concurrence à votre roadmap. Chaque semaine d'ingénierie consacrée au bot de démo est une semaine en moins pour le produit que vous vendez réellement.
• Le délai avant les premiers résultats. Il faut généralement des mois avant qu'une version interne fonctionnelle puisse être montrée sans risque aux acheteurs. Pendant ce temps, le pipeline qui justifiait le projet attend.

La comparaison honnête n'oppose donc pas un abonnement à un week-end de code. Elle oppose un abonnement à une équipe d'ingénieurs à temps partiel, indéfiniment, plus les deals perdus pendant la construction.

Quand est-il pertinent de le développer vous-même ?

Développer en interne est le bon choix quand ces trois conditions sont réunies :

1. Un agent de démo IA est au cœur de ce que vous vendez, et non un canal pour vendre autre chose.
2. Vous pouvez y affecter une équipe dédiée en permanence, pas le temps d'un sprint.
3. Attendre des mois avant que les acheteurs ne le voient ne vous pose pas de problème.

Sinon, la chose la plus utile que votre équipe puisse créer en vibe coding, c'est un prototype de ce qu'elle veut. Confiez cette liste de souhaits à une plateforme qui gère déjà les connexions, les sandboxes, les garde-fous, la voix, l'analytique et la transmission au CRM, et consacrez votre temps d'ingénierie à votre propre produit.

C'est exactement ce que fait Karumi. L'agent apprend votre produit en l'explorant, le pilote en direct tout en parlant à l'acheteur, et envoie chaque session dans votre CRM. La plupart des équipes sont en ligne en deux semaines, et c'est nous qui assurons la maintenance.

FAQ

Ne peut-on pas commencer par un prototype et changer plus tard ?

Si, et un prototype est un bon moyen de clarifier ce que vous voulez. Prévoyez simplement le budget de la transition : c'est après le prototype que se concentre l'essentiel du coût, et les acheteurs qui voient une démo cassée ne reviennent pas pour un second essai.

Et si notre produit change toutes les semaines ?

C'est l'argument le plus fort contre les parcours codés en dur. Karumi réapprend votre produit au fil de ses évolutions : une page renommée ou un bouton déplacé ne fait pas tomber la démo.

Perd-on le contrôle si on ne le développe pas soi-même ?

Non. Votre équipe écrit les scripts, choisit les parcours et définit les garde-fous. Ce que vous déléguez, c'est l'infrastructure : navigateurs, connexions, voix, sandboxes et intégrations.

Comment comparer les deux équitablement ?

Choisissez un parcours clé qui compte pour vos acheteurs et testez les deux dessus pendant une semaine : votre prototype et un agent Karumi, avec les mêmes questions. Comptez combien de fois chacun va au bout de la démo sans accroc.