Product Builder Night : Comment augmenter ses équipes produit (et l’ensemble de son organisation) avec l’IA 

Le futur n’est plus ce qu’il était. Le 28 avril dernier, à l’occasion de la Product Builder Night co-organisée par Converteo et Le Ticket, Charlotte Boquet (Lead Designer - Ornikar), John Kouto (AI Product Builder - Converteo) et Marie-Hélène Stoltz (Sales Ops & Stratégie - Alan) ont présenté leurs cas d’usage réels de l’IA pour gagner en productivité. Une évolution profonde du métier de product résumée en 3 parties. Synthèse.

⌛ 14 min de lecture pour s'augmenter avec l'IA

🎫 Les membres Premium du Ticket ont un accès intégral à cet article

 ✉️ Article issu du Ticket n°146

---

📌 TL;DR - Ce que tu vas apprendre dans cette synthèse de la Product Builder Night : 1- Chez Ornikar, un outil fait maison avec Claude Code pour permettre aux Product Managers de prototyper en autonomie… tout en respectant le design system 2- Chez Converteo, une architecture multi-agents pour s’augmenter avec l’IA et aller plus loin dans son travail de Product Manager 3- Chez Alan, des Product Builders au service des autres fonctions de l’entreprise - avec un framework de maturité IA en 3 étapes

"J'ai tout automatisé mon workflow avec l'IA", "Ce que je faisais en 10 jours ne me prend plus que 10 minutes aujourd’hui", “Plus besoin de Chief of Staff, j’ai ma flotte d’agents”... Difficile de ne pas se sentir largué en ce moment en ouvrant Linkedin. 

De belles promesses affichées… qui reflètent toutefois une réalité souvent édulcorée et difficilement actionnable au sein de son organisation.

D’où cette idée de Product Builder Night : une soirée avec un peu plus d’humilité, de démo concrètes, de retours de la vie réelle voire de partage d’imperfections. Et un peu moins de bullsh*t 😅

1- Chez Ornikar, un outil fait maison avec Claude Code pour permettre aux Product Managers de prototyper en autonomie… tout en respectant le design system !

À l'heure où les Product Managers prototypent à tout va grâce au vibe coding, comment faire en sorte qu’ils ou elles ne multiplient pas… le AI slop ?

C’est-à-dire des rendus qui semblent nickel à première vue mais qui, en réalité, nécessitent de tout refaire derrière, pour qu’ils respectent le design system. Et qui ne font pas vraiment gagner du temps. Au contraire.

C'est une tendance qu'on a rapidement vue apparaître chez Ornikar. On s'est vite dit qu'il fallait creuser ce sujet car le risque, c’était de se retrouver avec des boutons qui n'existent pas, des couleurs inventées ou une cohérence approximative”, témoigne Charlotte Boquet, la lead designer de l’auto-école en ligne.

Paddock, le garde-fou du design system d’Ornikar pour cadrer les Product Managers

La designeuse explore depuis plusieurs mois déjà comment l’IA peut l’aider dans son métier, notamment en interviewant des pairs pour connaître leurs usages. Jusqu’à se focaliser sur ce cas précis de la reproduction d’écran via l’IA, qui répondait à ce vrai problème interne.

Avec Hamza, son binôme Lead Product Manager, elle mène ce projet en 3 phases :

• Elle commence par envoyer une maquette à Claude (NDLR : l’IA d’Anthropic) avec des prompts simples. Encourageant… mais peu fiable ! L’IA inventait des composants…

• Ils vont plus loin ensuite en expliquant à Claude comment fonctionnent les vrais composants. D'abord en investissant une semaine de boulot avec un design system maison (= des liens Figma). Mais difficilement maintenable dans le temps. Puis en se liant directement à la codebase - un jour de travail. Ce qui facilite la maintenance, grâce à une Skill : tous les matins, Claude vérifie si des composants ont évolué et les mets à jour si c’est le cas. Et là, game changer !

• Voyant la qualité des rendus, Charlotte et Hamza introduisent alors les équipes à ce nouvel outil vibe codé, afin qu’elles puissent directement y mener leurs projets de run.

Le petit nom de cette solution : Paddock. Un vrai garde-fou : les Product Managers peuvent désormais prototyper en s’appuyant sur une IA qui va respecter le design system. Démo 👇

Tout commence par la sélection de son équipe, puis la partie du produit sur laquelle la personne souhaite prototyper : Wize, l’outil interne pour l’assurance, ou l’app d’Ornikar. Elle se retrouve alors dans la réplique exacte en local du produit existant, en pouvant même choisir la configuration des utilisateurs (à partir de 1’00).

1er cas d’usage : Mener un projet à faible impact design en totale autonomie

Côté Product Manager, Paddock est utilisé dans 3 cas principaux :

• Proposer des idées aux designers
• Challenger les propositions des designers directement avec une maquette
• Prendre en charge des petits projets à faible impact design en totale autonomie (changement de wording, ajout d’une question dans un questionnaire, faire une variation d’un écran existant etc.)

Charlotte présente justement un premier cas vécu lié à ce dernier point : une Product Manager veut tester l'ajout d'un composant sur une page existante, ici un encart contenant un message, appelé un "highlight".

Pour la demo, Charlotte fait l’exercice avec un message spécifique pour les participants du meetup. Mais sa PM a vraiment travaillé de cette façon quand elle a fait son test.

Sur la vidéo, tu verras qu’une erreur apparaît. C'est aussi ça la réalité du vibe coding ! Une fois disparue, l'écran est mis à jour et le nouvel highlight est bien visible, à l'endroit demandé, en tous points conforme au Design System. 

À l’origine, il fallait être très précis sur les noms des composants, sinon Claude ne les retrouvait pas. Charlotte a depuis affiné l'outil en ajoutant un fichier “.md”, c'est-à-dire un document de contexte pour Claude, qui fait le lien entre le vocabulaire courant des Product Managers et les noms des composants du Design System. Par exemple, "encart" sera traduit par Claude en "highlight" (le vrai nom de ce composant dans le design system).

2e cas d’usage : Explorer une solution en tant que Product Manager

Celui-ci est doublement délicat : le projet est urgent ET touche au légal. Charlotte n'a pas la bande passante pour le traiter.

J'ai dit à ma PM : prends la doc et fais le travail. Je veux juste vérifier à la fin si c'est OK", relate-t-elle.

Comme on le voit sur cette vidéo, elle n'a eu qu'à ouvrir Paddock, se rendre sur la branche créée par sa PM (soit une copie de travail isolée du projet, sans impact sur la prod’) et contrôler que le nouveau flow est conforme au Design System - et responsive.

Les PM prototypent dans Paddock, les designers vérifient le résultat. Ce n'est pas du vibe coding libre, c'est un mode de collaboration structuré”, résume-t-elle.

Pour la petite histoire : Charlotte a donné son feu vert pour ce projet. La Product Manager se rapproche alors des développeurs pour la mise en production. Pas de Figma, pas de designer. Totale autonomie.

La fin des Product Designers… et de Figma ? (d’autant plus avec Claude Design)

En créant Paddock, Charlotte a-t-elle scié la branche sur laquelle elle est assise ?

Retrouve nos autres synthèses d'événements :