TPC

“Les designers doivent apprendre à coder.”

C’est probablement la phrase la plus répétée du moment dans la tech.
Pour Pantéa, le sujet est ailleurs.

Après 15 ans entre PayPal, TheFork, BlaBlaCar, Hopper et maintenant Beside, une startup IA américaine, elle observe surtout une transformation beaucoup plus profonde :
Le métier passe progressivement de la production d’écrans à la conception de systèmes agentiques.

Aujourd’hui, elle travaille directement dans Cursor et Claude Code pour explorer, prototyper, documenter et shipper dans des équipes où les frontières entre design, produit et engineering deviennent de plus en plus floues.

Le 28 mai, elle viendra partager comment l’IA transforme concrètement son quotidien de designer et pourquoi elle pense que la valeur du designer de demain se jouera davantage dans le jugement, les systèmes et la compréhension business que dans la simple production d’interfaces.

Au programme :

1️⃣ Pourquoi Figma n’est plus l’outils central du métier
→ Ce que l’IA a réellement changé dans son workflow
→ Pourquoi elle travaille aujourd’hui directement dans Cursor et Claude Code
→ Ce que les designers risquent de manquer en restant uniquement dans l’interface

2️⃣ Le passage du design d’interfaces au design de systèmes
→ Concevoir des produits majoritairement agentiques et back-end
→ Penser workflows, orchestration et niveaux de confiance
→ Pourquoi le métier devient de plus en plus systémique

3️⃣ Quand tout le monde devient builder
→ Développeurs, PMs, designers : des frontières de plus en plus poreuses
→ Les nouveaux enjeux de cohérence produit
→ Ce que devient réellement le rôle du design dans ce contexte

4️⃣ Le vrai avantage des designers en 2026
→ Pourquoi l’UX/UI seule ne suffit plus
→ Pourquoi le code seul ne suffit pas non plus
→ Ce qui crée désormais de la valeur : jugement, goût, vision produit et compréhension business

🎒 Vous repartirez avec :
→ Une vision concrète de l’évolution du métier
→ Des exemples réels de conception de produits agentiques
→ Un workflow moderne mêlant IA, design et produit
→ Une autre lecture du futur du design que le simple débat “les designers doivent-ils coder ?”

🗓️ Jeudi 28 mai 2026 • 12h
📍 Live interactif en ligne

Aujourd'hui, faire un produit IA qui marche, c'est facile.

Faire un produit IA qui marche bien, qui se comporte
exactement comme prévu, c'est devenu un autre métier.

C'est le quotidien d'une équipe qui ship plusieurs produits IA en production, dans une fintech, pour de vrais clients.

Marianne Borzic Ducournau dirige l'équipe ML / Data Science produit de Qonto.

↳ 4 ans chez Qonto : d'abord à la tête d'une équipe data science orientée décision interne, aujourd'hui sur le produit client
↳ Une grande partie de sa carrière passée à San Francisco avant de rentrer en France
↳ Son équipe ne fait pas de la recherche : elle livre du ML directement dans le produit que les clients Qonto utilisent
Peu de fintechs ouvrent le capot sur la façon dont elles construisent et fiabilisent leur IA. Marianne va le faire.

Voici ce qu'on va couvrir :
1. ML "interne" vs ML "produit" : deux métiers distincts
→ La distinction que la plupart des boîtes confondent
→ Pourquoi une équipe ML produit n'est pas un lab de R&D
→ Ce que ça change concrètement dans la façon de prioriser

2. Zoom sur 4 produits IA en prod — 4 stacks différentes
→ OCR & extraction de factures : de la photo du reçu au virement pré-rempli
→ Réconciliation documents / transactions : le matching qui automatise la compta du client
→ Catégorisation temps réel : la brique fondatrice du cash management
→ L'analyste conversationnel : des milliers d'entreprises qui interrogent leurs données en langage naturel

3. Le vrai sujet : évaluer une IA qui ne répond jamais deux fois pareil
→ Pourquoi évaluer un modèle ML classique était simple, et un LLM ne l'est plus
→ Comment savoir qu'une IA "qui marche" marche vraiment
→ Pourquoi un environnement financier régulé ne laisse aucune marge sur cette question

4. Le métier de ML engineer a changé en 12 mois
→ Ce que font les MLE de Marianne aujourd'hui vs il y a un an
→ Pourquoi une équipe SWE + MLE est déséquilibrée sans l'un des deux
→ Ce que ça veut dire pour ta propre trajectoire dans la data et l'IA

🎒 Tu repartiras avec :
→ Une grille claire pour distinguer un produit IA "qui marche" d'un produit IA fiable
→ 4 patterns concrets de produits IA en prod, réutilisables sur tes propres cas
→ Une méthode pour penser l'évaluation dès la conception, pas après le bug
→ Une lecture honnête de l'évolution du métier ML, pour ne pas te faire dépasser

📺 Mercredi 3 juin 2026 — 12h00
Format : 60 min, masterclass + Q&A en direct

Un prototype Figma qui prend 2 semaines à finir.
Un Figma round avec le designer pour caler le pixel-perfect.
Une réécriture from scratch côté dev une fois la maquette validée.

Le prototype et la prod, c'est deux mondes.
Tu construis pour aligner. Tu réécris pour livrer.

Sauf que chez @Zoom, un Senior PM a décidé que non.
Pas un side project. Pas un POC dans son coin.

Une feature CRM livrée en production en 2 semaines, avec 2 devs, zéro designer full-time, et un prototype généré par Claude Code qui a servi de base directe au code final.

Le 4 juin 2026, Lucas Didier (Senior PM @Zoom) raconte comment il a court-circuité Figma sur une feature critique, et ce que ça change pour le rôle d'un PM.

Ce qu'on va décortiquer ensemble :

1️⃣ Le pari : sauter Figma, viser le code de prod direct
→ Le contexte : une feature CRM email à livrer en moins d'un mois, 2 devs, zéro designer full-time
→ Le design process classique chez Zoom, et ce qu'il a décidé de tenter à la place
→ Pourquoi prendre ce risque maintenant et pas il y a 6 mois

2️⃣ La sauce secrète : un Prototype Kit qui connaît son design system
→ Comment encoder un design system pour que Claude Code le respecte vraiment
→ Le prompt utilisé et l'output généré, partagés en direct
→ Pourquoi un Prototype Kit fait la différence vs un prompt one-shot

3️⃣ Du prototype au code de prod : la bascule
→ Le hosting via Cloudflare Pages + GitHub pour partager le proto à toute l'équipe
→ Prototype et feature finale, côte à côte : ce qui a été repris, ce qui a été retravaillé
→ Comment l'équipe s'est alignée AUTOUR du proto au lieu d'attendre un Figma

4️⃣ Quand ça marche, quand ça marche pas, et le shift de rôle PM
→ Les cas où le workflow a tenu, ceux où il a craqué
→ Quand un PM doit builder son propre proto, et quand il faut revenir à Figma
→ Le shift plus large : les PMs comme builders à l'ère des AI coding tools

🎒 Tu repartiras avec :
- Un playbook concret pour construire un Prototype Kit qui encode ton design system
- La stack utilisée chez Zoom (Claude Code + Cloudflare Pages + GitHub) pour livrer sans Figma
- Les arguments pour proposer ce workflow à ton équipe dès la semaine d'après
- Une vision claire de quand le pari paye, et quand il faut revenir au Figma classique

🗓 Jeudi 4 juin – 12h00
📍 Live interactif + Q&A
💬 Pour PMs, Senior PMs, Lead PMs et tous les builders curieux du futur des AI coding tools