De quoi parle cet article. Un exemple concret illustratif, pas un résultat client. L'équipe fintech, son produit et chaque chiffre sont des hypothèses. Il montre ce qu'il faut pour transformer un prototype AI qui fait bonne figure en démo en une fonctionnalité que vous pouvez mettre devant tous les utilisateurs.
Supposons une équipe produit d'une fintech en série b. Un product manager a construit en un week-end un prototype de fonctionnalité AI dans lovable. Il a l'air réel et il a bien fait en all-hands. Puis il reste là, parce qu'avoir l'air réel et être fiable sont deux métiers différents.
à propos de cet exemple : l'équipe est générique et aucun client n'est derrière. Rien ici n'est un résultat livré ni une projection. Le design est le sujet, 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 passe-t-on un prototype AI en production ?
Partez du vrai problème, pas de l'interface de démo. Reconstruisez la fonctionnalité dans votre propre produit avec des réponses en streaming, une suite de tests qui compare les réponses à des cas valides connus, un journal d'audit et une revue humaine là où c'est utile. Mesurez ensuite les tickets de support sur la fonctionnalité avant et après.
#Qu'inclut le design de production ?
Ne partez pas de la zone de chat du prototype. Partez de la file du support. Supposons que les trois tickets au plus gros volume sur cette fonctionnalité pointent vers la même chose : les utilisateurs n'obtiennent pas de réponse claire sans écrire au support. Construisez la fonctionnalité pour répondre d'abord à ces trois questions, dans le produit et le design system de l'équipe, pas comme un widget plaqué.
- 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
On reconstruit un prototype bloqué en fonctionnalité livrée, avec streaming, suite de tests, journal d'audit et UX native dans le produit.
We aren't
On ne pose pas une zone de chat générique sur le produit en l'appelant fonctionnalité AI.
#Comment savoir si la fonctionnalité réduit les tickets de support ?
Construisez la fonctionnalité à rebours à partir des tickets. Les questions qui génèrent le plus de volume de support sont celles auxquelles la fonctionnalité répond dans le produit, avant que quiconque ait à écrire. Le journal d'audit montre quelles questions elle traite et lesquelles arrivent encore à une personne. Ce même journal aide à distinguer une vraie baisse d'un creux saisonnier : comparez le volume de chaque type de ticket à une fenêtre de référence antérieure au lancement.
La suite de tests est ce qui fait tenir toute amélioration. Avant le lancement, chaque changement est exécuté contre les réponses valides connues. Une modification de prompt qui corrige un cas et en casse deux autres est repérée avant d'atteindre un utilisateur. C'est la différence entre une démo qui marche une fois et une fonctionnalité qui marche à chaque fois. Les équipes produit appellent ça livrer. Nous aussi. Plus sur notre approche du travail produit, ici.
#Dans quel ordre le construit-on ?
D'abord le journal d'audit et la suite de tests, parce qu'on n'améliore pas ce qu'on ne mesure pas. Ensuite, reconstruire dans le produit les réponses aux tickets principaux. Puis l'UX du design system et le streaming. Enfin, un déploiement par paliers vers une part croissante des utilisateurs, en surveillant le journal d'audit pour tout ce que les tests ont raté. Pas de lancement massif d'un coup.
Le test à appliquer : on doit passer de quelque chose qu'on a démontré à quelque chose qu'on a livré, et la file du support est la preuve que ça a marché.
Voilà ce que nos exemples concrets ont en commun. Ce n'est pas le modèle qui compte. Ce sont les parties ennuyeuses autour : la suite de tests, le journal d'audit, les portes de revue, le déploiement qu'on peut surveiller. C'est ce qui transforme un prototype en quelque chose que vous pouvez mettre devant tous les utilisateurs. Si vous avez un build v0 ou lovable bloqué à la démo sans chemin pour avancer, c'est exactement l'écart qu'on comble. dites-nous ce que vous construisez.
