ce qu'est cet article. un regard en public sur une mission. une équipe produit fintech en série b avait une fonctionnalité ia qui faisait bonne impression en démo mais ne partait jamais en production. nous l'avons reconstruite en fonctionnalité de production en 5 semaines. elle est allée à 100 % des utilisateurs, et les tickets support sur cette fonctionnalité ont chuté de 60 % après le lancement.
le prototype existait déjà. un chef de produit l'avait construit sur lovable en un week-end. il avait l'air réel. il a fait bonne impression en réunion générale. puis il est resté sans suite pendant quatre mois, parce qu'avoir l'air réel et être fiable sont deux choses différentes.
divulgation préalable : le client est anonymisé. le déploiement en 5 semaines et la baisse de 60 % des tickets sont les chiffres livrés de la mission, pas des projections. nous ne le nommons pas parce que le contrat l'interdit. ici, c'est la construction qui compte, pas le logo.
#pourquoi un bon prototype cale-t-il avant la production ?
parce que le prototype répond à une question différente de celle de la production. le prototype prouve que l'idée peut fonctionner une fois, sur une entrée propre, avec le fondateur aux commandes. la production doit fonctionner sur une entrée désordonnée, à 2 heures du matin, sans personne pour surveiller, et rester défendable quand un client conteste ce que la fonctionnalité lui a dit. c'est cet écart qui tue la plupart des constructions v0 et lovable. pas parce que l'idée était mauvaise. parce qu'il n'existait aucun chemin entre la démo et la chose sur laquelle on peut mettre son nom.
comment faire passer un prototype ia en production ?
partez du vrai problème, pas de l'interface de démo. reconstruisez la fonctionnalité à l'intérieur de votre propre produit avec des réponses en streaming, une suite de tests qui vérifie les réponses face à des cas de référence connus, un journal d'audit, et une relecture humaine là où elle compte. pour cette équipe fintech, ce chemin a pris 5 semaines et fait chuter les tickets liés à la fonctionnalité de 60 %.
#qu'avons-nous concrètement construit ?
nous ne sommes pas partis de la fenêtre de chat du prototype. nous sommes partis de leur file de support. les trois types de tickets les plus fréquents sur cette fonctionnalité pointaient tous vers la même chose : les utilisateurs ne pouvaient pas obtenir de réponse claire sans écrire au support. nous avons donc construit la fonctionnalité pour répondre d'abord à ces trois questions, à l'intérieur de leur propre produit et de leur propre système de design, pas comme un module ajouté après coup.
- des réponses en streaming pour que la fonctionnalité paraisse immédiate au lieu d'afficher une roue de chargement. la réponse s'écrit au fur et à mesure qu'elle se forme.
- une suite de tests qui confronte la fonctionnalité à des réponses de référence connues à chaque changement, pour qu'une retouche d'un prompt ne puisse pas casser un autre cas sans qu'on le remarque.
- un journal d'audit sur chaque réponse, pour que si un client conteste ce que la fonctionnalité a dit, le support puisse retrouver exactement l'entrée et la sortie.
- une interface intégrée au produit, construite dans leur propre système de design, pour qu'elle se lise comme une partie du produit, pas comme une fenêtre de chat greffée dessus.
we are
nous avons reconstruit un prototype à l'arrêt en une fonctionnalité livrée, avec streaming, suite de tests, journal d'audit et interface native intégrée au produit.
we aren't
nous n'avons pas posé une fenêtre de chat générique sur le produit en l'appelant fonctionnalité ia.
#pourquoi les tickets support ont-ils chuté de 60 % ?
parce que nous avons construit la fonctionnalité à rebours, à partir des tickets. les trois questions qui généraient le plus de volume de support sont désormais les trois auxquelles la fonctionnalité répond directement dans le produit, avant qu'un utilisateur n'ait à écrire à qui que ce soit. le journal d'audit nous indique quelles questions la fonctionnalité gère et lesquelles atteignent encore un humain. c'est ce même journal qui nous a permis de savoir que la baisse de 60 % était réelle et pas un simple creux saisonnier. elle est mesurée, par type de ticket, contre les huit semaines précédant le lancement.
la suite de tests explique pourquoi la baisse a tenu. avant le lancement, chaque modification passait par les réponses de référence connues. une retouche de prompt qui corrigeait un cas tout en cassant deux autres était détectée avant d'atteindre un utilisateur. c'est la différence entre une démo qui fonctionne une fois et une fonctionnalité qui fonctionne à chaque fois. les équipes produit appellent ça livrer. nous sommes d'accord. plus sur notre façon d'aborder le travail produit ici.
#combien de temps a pris le déploiement ?
cinq semaines, du prototype à 100 % des utilisateurs. la première semaine a servi au journal d'audit et à la suite de tests, parce qu'on ne peut pas améliorer ce qu'on ne mesure pas. les semaines deux et trois ont reconstruit les trois réponses les plus demandées à l'intérieur du produit. la semaine quatre a été consacrée à l'interface dans le système de design et au streaming. la semaine cinq a été un déploiement progressif, dix pour cent des utilisateurs à la fois, en surveillant le journal d'audit pour tout ce que les tests auraient manqué. pas de lancement massif d'un coup. pas de reconstruction étalée sur un trimestre.
c'est passé d'une chose qu'on montrait en démo à une chose qu'on a livrée, et c'est la file de support qui nous dit que ça a marché.
c'est ce que la plupart de nos études de cas en public ont en commun. le gain ne vient pas du modèle. il vient des parties ingrates autour de lui : la suite de tests, le journal d'audit, les points de relecture, le déploiement qu'on peut surveiller. c'est ce qui transforme un prototype en quelque chose que l'on peut mettre devant chaque utilisateur. si vous avez une construction v0 ou lovable bloquée en démo sans suite, c'est exactement l'écart que nous comblons. dites-nous ce que vous construisez.