Depuis bientôt 2 ans, la GenerativeAI bouleverse les codes du digital, et ouvre la porte à de nouvelles expériences de consommation et de recherche. Carrefour, ManoMano, Decathlon : les plus grands leaders du retail expérimentent avec la GenerativeAI, pour offrir de nouvelles expériences de navigation à leurs utilisateurs. La conception d’un produit GenAI est d’autant plus complexe que le PM doit savoir placer le curseur au bon niveau pour construire un produit novateur tout en restant viable, utilisable et désirable par ses utilisateurs.
J’ai eu l’occasion d’apprendre sur la GenerativeAI en travaillant pendant 1 an sur un assistant personnel IA.
Le principe du produit est le suivant :
- l’utilisateur entre sur la pop-in de l’assistant et peut indiquer la demande qu’il souhaite : par exemple “Je voudrais une robe d’été rouge”
- Une fois la demande envoyée, notre assistant fait le match entre la demande utilisateur et notre BDD de produits en utilisateur le système d’embeddings d’OpenAI. Suite à ce match, l’assistant génère une réponse en langage naturel composée d’une courte description du produit et d’une image cliquable.
En tant que PM, travailler sur ce concept GenerativeAI présente plusieurs enjeux : il faut maîtriser le travail de conception et gestion des développements du produit, tout en composant avec un output produit très peu prédictible et non déterministe.
Suite à cette expérience, je détaille ici 3 apprentissages clé pour réussir son produit GenAI. Ces apprentissages s’imbriquent dans l’ensemble du flux de conception & delivery d’un produit : conception produit, développements & tests.
I. Conception Produit : se focaliser d’abord sur un cas d’usage très précis pour maximiser l’attractivité du produit et accélérer le time to market
Lorsque nous avons commencé l’implémentation de notre personal shopper, nous avons opté pour une stratégie simple: maitriser un type très spécifique de demandes utilisateurs, qu’on appellera ici “input”, pour pouvoir mieux contrôler notre output, qui est ici la réponse de l’IA. Ensuite, une fois le premier “input” maitrisé, nous élargissions notre champ d’action pour pouvoir gérer un plus grand nombre de demandes utilisateurs.
Le fait d’itérer et “versionner” son produit présente plusieurs avantages:
- Cela permet de tester son produit plus rapidement sur le marché et collecter des retours utilisateurs. Ceci a d’autant plus de valeur sur un produit IA qui se veut non déterministe et difficilement contrôlable, et où il est crucial de comprendre le comportement utilisateur pour faire évoluer le produit dans les bon sens. Utiliser des outils d’analyse de comportements utilisateur (i.e. Hotjar) est aussi clé pour identifier les points de friction et de potentielles améliorations à apporter au produit.
- En mettant en production rapidement, l’équipe technique acquiert de l’expertise sur le modèle et peut mieux anticiper les outputs produit. Cette expertise peut orienter les développements pour tester de nouvelles fonctionnalités et améliorer la performance du modèle. Par exemple, après avoir mis en production notre première version, l’équipe technique a voulu tester une nouvelle mise à jour de ChatGPT: le ‘GPT function-calling”. Cette fonctionnalité permettait à notre modèle de différencier les demandes utilisateurs “simples” des plus complexes, ce qui a permis d’augmenter notre trafic et conversion.
Plus concrètement, nous avons itéré sur notre produit en augmentant progressivement le nombre d’inputs utilisateurs géré par le modèle. Notre assistant ne pouvait d’abord que gérer les demandes de produit uniques, sans forcément répondre avec les caractéristiques demandées, puis pouvait ensuite gérer les demandes de produit multiples, avec de plus en plus de pertinence.
Voici une illustration simple de nos versions.
Cette stratégie nous a permis de sortir notre ‘MVP’ en moins de 2 mois, et de recueillir très rapidement des retours d’expérience utilisateurs sur notre V1, nous permettant de construire nos prochaines versions pour répondre à de réels besoins utilisateurs.
II. Conception technique & développements : Anticiper au maximum les edge case et régressions du modèle pour ne pas perturber la phase de développements
Le challenge du projet était d’assurer la livraison du produit dans les temps, tout en gérant les retards et les régressions engendrés par notre modèle d’IA.
Du fait du non-déterminisme d’un produit GenAI , il y’a risque plus important d’hallucinations ou d’output produit non souhaités que sur un produit plus classiques. Ces régressions techniques sont plus difficilement détectables que sur un produit classique, et ont souvent eu un impact négatif sur notre phase de delivery en affectant nos fonctionnalités existantes.
J’ai observé ce cas lorsque nous avons testé la fonctionnalité du fine tuning d’OpenAI pour améliorer la pertinence de nos recommandations produit. Le fine tuning permet de faire ingérer à notre modèle un data set avec une liste d’inputs et d’outputs précis : par exemple, pour une demande très spécifique, telle que “Je veux une robe bleue”, le modèle sera conditionné à répondre avec la bonne catégorie de produit et la bonne couleur.
Nous avons dédié 1 semaine pour la conception et 1 semaine pour l’implémentation de cette nouvelle feature. Au final, nous avons du faire marche arrière : le data set ne peut contenir que 100 combinaisons input-output, donc un nombre limité, et détériorait la pertinence de nos recommandations. Nous n’avions pas anticipé ces mauvais résultats car nous n’avions pas testé la solution en amont, et nous disposions d’assez peu de documentation sur cette nouvelle fonctionnalité.
Pour pallier ce genre d’imprévus, il est important de cadrer le développement de nouvelles fonctionnalités en plusieurs étapes:
- Réalisation ArchitectureDecisionRecords : Lorsque notre itération impliquait un choix de technologie (ex ChatGPT vs Microsoft), l’équipe technique réalisait un ADR (Architecture Decision Records), outil de recommandation technique très utilisé chez Theodo, qui impliquait forcément un test de ces technologies sur notre application en staging. Cet ADR nous permet d’évaluer les bénéfices et risques de ce choix technique et de limiter les impacts négatifs sur le produit en faisant un choix éclairé. L’ADR nous permettait aussi d’avoir un historique clair de l’ensemble de nos itérations techniques.
- Privilégier une phase de documentation et de POC sur 1 à 2 semaines: Lors d’itérations à fort enjeu, nous optons pour une phase d’étude de la documentation et de test en mode POC de la fonctionnalité pour s’assurer de sa compatibilité avec notre application existante. La documentation permet d’expliciter les bénéfices et les risques de la nouvelle fonctionnalité et d’arbitrer en équipe sur sa mise en production. Par exemple, nous avions testé GPT 4.5 turbo sur un environnement local pour tester et documenter nos résultats. **Nous testions ensuite la nouvelle fonctionnalité sur un temps court, 1 semaine maximum, pour évaluer rapidement sa pertinence.
III. Tests : S’aligner sur une méthode de tests pour réduire l’incertitude de résultats de l’IA
Un autre challenge pour le PM est la stratégie de tests du produit GenAI. Du fait de l’imprévisibilité du modèle, et malgré les quelques moyens de “contrôle” existants, tels que le prompt engineering, les usecases GenerativeAI conservent une part non négligeable “d’hallucinations”. Cela rend la tâche de recette du PM, normalement assez linéaire lors de projets plus classiques; très compliquée. En effet, des questions spécifiques se posent, en particulier lors des tests de modèles de génération de texte ou d’image: “Quel volume dois-je tester ? Quels scenarii ? Quel degré de succès est considéré comme “satisfaisant”? Comment puis-je repérer les cas limites facilement? "
Pour répondre à ces questions, je systématise le processus de tests en créant une page de tests avec un format très précis à chaque nouvelle mise en production (toutes les 2-3 semaines).
Voici le contenu de la page illustré ci-dessous:
Nous décidions de mettre la fonctionnalité en production si au moins 80% de tous les tests étaient “OK”.
Cette méthode de tests permettaient à l’équipe de s’assurer du bon fonctionnement du produit pour nos cas connus, et permettait de repérer de potentielles régressions apportées par de nouveaux développements, plus fréquentes avec un modèle non déterministe comme les modèles de GenerativeAI.
Aussi, tester un grand volume de prompts permet au PM et à l’ensemble de l’équipe d’acquérir de la connaissance et de l’expertise sur le modèle et d’affiner les améliorations apportées au modèle.
Conclusion
La compréhension de la singularité d’un produit “GenAI powered” est essentielle pour le PM : le modèle non-déterministe et l’imprédictibilité du modèle obligent le PM et son équipe à innover sur le flux de conception classique du produit.
Tout d’abord, la conception produit doit être revue par rapport à un produit classique pour se focaliser sur un cas d’usage simple et facilement compréhensible par les utilisateurs. Suite à ça, la mise sur le marché doit être rapide pour collecter le plus de retours utilisateurs possible et itérer de manière précise et pertinente sur son produit.
Ensuite, à chaque nouvelle fonctionnalité apportée, il faut adopter une stratégie de conception technique minutieuse en réalisant un ADR, pour être sure de l’équilibre bénéfices/coûts par fonctionnalité; et ensuite faire un POC rapide pour tester le succès de la fonctionnalité au plus vite.
Enfin, avant de mettre en production, le PM doit établir une stratégie de tests bien rôdée, en s’alignant avec l’équipe sur une base d’inputs “de base” à tester, un volume critique à tester et un taux de réussite du test, qui détermine la future mise en production ou non.
