ia pour les équipes produit : de v0 à une fonctionnalité qui tient

ia pour les équipes produit. l'ia pour les équipes produit, c'est livrer une fonctionnalité ia dans les surfaces de votre propre produit que les utilisateurs adoptent et continuent d'utiliser. pas une démo. une fonctionnalité avec un taux de rétention et un nombre de tickets de support pour l'attester.

la plupart des équipes produit ont déjà un prototype. vous l'avez construit en week-end avec Lovable, Bolt, ou v0. il était impressionnant en démo. puis il a calé avant d'arriver en production.

le problème n'est pas le modèle. le problème, c'est tout ce qui l'entoure. le streaming, les évaluations, les logs d'audit, et un endroit dans le produit où l'utilisateur se trouve déjà. c'est ce qui sépare un écran v0 d'une fonctionnalité que vos utilisateurs gardent.

#pourquoi le prototype cale-t-il avant le lancement ?

un prototype répond à une question : est-ce que le modèle sait faire la chose. une fonctionnalité en production répond à quatre de plus. est-ce qu'elle envoie les réponses en streaming pour que l'utilisateur ne regarde pas un indicateur de chargement. est-ce qu'elle reste correcte quand le prompt change. peut-on prouver ce qu'elle a dit à un client il y a six semaines. et est-ce qu'elle vit là où l'utilisateur travaille déjà, pas derrière un autre onglet.

#faut-il greffer une boîte de chat ou intégrer ia dans vos surfaces ?

le réflexe par défaut, c'est une bulle de chat flottante dans le coin. ça se livre vite. ça reste aussi inutilisé, parce que votre utilisateur n'est pas venu pour bavarder. il est venu pour effectuer un paiement, vérifier un relevé ou ouvrir un litige.

la meilleure option est d'intégrer l'ia dans la surface où cette tâche se fait. une valeur par défaut intelligente dans le formulaire. une explication en un clic à côté de la transaction. une réponse affichée dans le panneau que l'utilisateur avait déjà ouvert.

#à quoi ça ressemblait pour une fintech en série B ?

une fintech en série B est venue nous voir avec un assistant ia orienté client construit dans Lovable. il répondait aux questions en démo. il ne pouvait pas passer en production. pas de streaming, pas de moyen de mesurer la qualité, pas de piste d'audit pour un produit régulé.

• streaming : les réponses s'affichent token par token, l'utilisateur voit la réponse se former plutôt qu'un indicateur de chargement.
• suite d'évaluations : un ensemble fixe de vraies questions s'exécute à chaque changement de prompt, pour que la qualité ne régresse pas silencieusement quand quelqu'un modifie le prompt système.
• logs d'audit : chaque réponse est enregistrée avec ses entrées, pour qu'une fintech régulée puisse prouver ce qu'un client a reçu et quand.
• ux dans le produit : l'assistant répond dans la vue de transaction que l'utilisateur avait déjà ouverte, pas dans un onglet de chat séparé.

nous l'avons déployé à 100 % des utilisateurs en 5 semaines. les tickets de support sur cette fonctionnalité ont baissé de 60 % après le lancement, parce que les utilisateurs obtenaient la réponse dans le produit au lieu d'ouvrir un ticket pour la demander.

le prototype a prouvé que les gens en voulaient. le build en production est ce qui les a fait continuer à l'utiliser. la baisse de 60 % des tickets, c'est ce qui intéressait notre cfo.

#comment cadre-t-on un build comme celui-ci ?

on le fait passer par le service de build : périmètre fixe, forfait fixe, et le code est à vous dès le premier jour. vous gardez le prototype que vous avez déjà créé en v0, Bolt, ou Lovable comme point de départ. on l'emmène jusqu'à une fonctionnalité dans votre produit.

si vous voulez le schéma spécifique à votre équipe, la page ia pour le produit détaille où l'ia trouve sa place dans un produit, et la pratique de conseil est l'endroit où ces builds se font. envie des preuves avant de vous engager ? voir les réalisations.