Pantéa est designer avec seize ans d'expérience dans la tech, passée par PayPal, La Fourchette (TripAdvisor), BlaBlaCar, Hopper et Swile. Elle est aujourd'hui chez Beside, une startup agentique qui gère des appels professionnels par IA. Dans ce live, elle pose une thèse claire : le débat "faut-il coder ?" est le mauvais débat. Le vrai enjeu, c'est de comprendre ce qu'on conçoit et ce qu'on conçoit a fondamentalement changé. Depuis six mois, Pantéa entend partout que les designers doivent absolument savoir coder. Elle pense qu'on se trompe de débat. Pas parce que le code n'a pas d'importance. Mais parce que la vraie transformation du métier se passe ailleurs : dans le passage du design d'interface au design de système, du design de ce qu'on voit au design de ce qu'on ne voit pas.
1. Une posture qui s'est construite par les contextes
Pantéa commence chez PayPal en 2014, entre Paris et San Francisco. Une révélation : aux États-Unis, le designer n'est pas un graphiste. Il fait de la discovery, travaille avec PM et développeur dès le kick-off, fait de la recherche utilisateur. "En France, le designer était vu comme un graphiste. Pas aux États-Unis."
Chez La Fourchette (rachetée par TripAdvisor), elle arrive dans une culture design plus immature. Elle implante le double diamant et les pratiques de co-construction : trois personnes dès le kick-off, itérations rapides, tests utilisateurs. Ses plus gros wins : augmentation des booking rates et réduction des no-shows.
Chez BlaBlaCar, elle prend en charge tout ce qui est paiement. Chez Hopper concurrent d'Expedia, full remote elle a un ownership fort sur toute la partie paiement (wallet, referral, gamification de la rétention) sans PM front. Elle challenge et propose la roadmap tous les trois mois. "C'est là où j'ai appris le distributed ownership : on shippait tous les deux semaines quelque chose. Le designer avait une casquette PM très forte."
Chez Swile en freelance, puis chez Beside, où on lui propose de designer un agent IA. "Quand on m'a parlé d'un agent IA à construire, c'est là où je me suis dit que ma carrière doit évoluer et que j'aimerais travailler dans un produit agentique."
Beside est une intelligence artificielle qui gère des appels professionnels : comprend les clients, répond à leur place, booke des rendez-vous, envoie des SMS, met à jour des CRM, envoie des récaps. Pantéa s'occupe de tous les systèmes agentiques de la boîte.
2. Le temps d'itération a implosé
L'ancien workflow que Pantéa décrit : discovery, wireframes, maquettes Figma, validation tech, itérations, livraison au développeur, ajustements. Des loops de plusieurs semaines. Et un symptôme récurrent : "On shippait le MVP et on partait sur un autre sujet alors qu'on avait une vision idéale. À force d'attendre, d'analyser, d'autres priorités arrivaient. La vision idéale n'est jamais sortie, ou bien après ce qu'on avait estimé."
Aujourd'hui chez Beside : scope, recherche utilisateur, prototype dans le code directement, démo via Loom, branche Git partagée, rollout progressif, mesure.
Figma est devenu un notepad. "J'ai des idées, je les dessine. Parfois un visuel vaut dix mille mots. Je vais faire une carte, la partager. Il comprend et me fait le reste du flow." Ce qui a changé concrètement : "On est passé de semaines à quelques heures. En une journée, on peut avoir un produit qu'on valide. En trois jours, c'est en prod."
Deux branches systématiques dans chaque sujet : une branche MVP (ce qu'on peut sortir et tester tout de suite) et une branche vision idéale. Les deux sont prototypées, partagées, discutées. "Le but, ce n'est pas que ce soit parfait. Le but, c'est que ce soit cohérent et on roll out."
Sur les revues : "Les devs front sont aussi beaucoup plus produit. On review ensemble. Parfois, ils reprennent mon sujet. Parfois, ils ont leurs propres initiatives. Il y a une casquette produit. Si vous n'aimez pas faire du produit, c'est là où ça va coincer."
"Il n'y a plus de problème de pixels. On n'a plus besoin de wireframing. Je suis directement dans le produit réel. Et tout le monde se projette directement dans le produit réel."
3. On ne conçoit plus des écrans. On conçoit des comportements.
Pantéa formule un changement de fond : "Hier, on dessinait ce que l'utilisateur voit. Aujourd'hui, on conçoit ce qu'il ne voit pas."
La structure d'un produit agentique : un utilisateur a une intention. Un agent la prend en charge. Cet agent est défini par un modèle, des outils (CRM, calendrier, autres services), une mémoire, et des politiques ce qu'il peut faire et ce qu'il ne peut pas faire. Le résultat est minimaliste côté interface. Mais la complexité en dessous est élevée. "Il faut comprendre ce qui se passe ici pour pouvoir avoir une UI qui marche bien."
La décision centrale dans le design d'un agent : jusqu'où lui faire confiance ? "C'est la vraie question. Et tout le sujet, il est autour de la confiance."
Quatre niveaux d'autonomie
1. L'agent suggère
"Si j'étais toi, la tarte, je la ferais cuire à cette température."
2. L'agent demande la permission
"Est-ce que tu veux que je te donne le timing parfait pour cette recette ?"
3. L'agent agit en prévenant
"Je vais appeler ta mère pour avoir la recette précise. Confirmation ?"
4. L'agent agit sans prévenir
Il a appelé, a obtenu la recette, et te la pousse. "Là, le risque est hyper élevé. Tu n'avais peut-être pas envie qu'on dérange ta mère."
"Quand on construit un agent, on commence par des niveaux de risque très faibles. Jusqu'à ce que l'utilisateur ait confiance et qu'on n'ait plus besoin de demander la permission."
Les nouvelles questions du designer sur un produit agentique : quand l'agent doit-il demander une confirmation ? Que doit voir l'utilisateur de ce qui se passe ? Comment l'utilisateur reprend-il la main ? Comment on se rattrape d'une erreur silencieuse ?
"On design des choses que l'utilisateur ne voit pas. Il y a une partie UI, il y a encore des écrans, elle est minimaliste, mais elle est vraiment beaucoup plus petite. Et ce qui est important en dessous, c'est des comportements, des politiques, des règles."
4. Prompter un comportement empathique sur Cursor
Pantéa montre en live comment elle a prototypé un cas d'usage pour la démo : un agent réceptionniste pour un salon de coiffure.
Le prompt envoyé à Cursor : quand quelqu'un mentionne un mariage, des cheveux abîmés ou un événement important, créer une chip "urgent" dans la liste des appels, envoyer un SMS pour demander des photos des cheveux, adopter un ton empathique, ne pas donner de prix.
L'agent comprend l'intention. Il crée les règles conditionnelles. La conversation démo montre l'agent en action : "Wow, ça semble vraiment stressant, surtout avec le mariage demain et les cheveux abîmés en plus. Je comprends l'urgence." Il propose d'envoyer un texte pour recevoir des photos avant de donner un devis, demande le prénom de la personne, propose un rappel humain.
La partie SMS n'a pas fonctionné pendant la démo. Ce que Pantéa ferait ensuite : "Je lui dirais la partie SMS n'a pas fonctionné. Pourquoi ? Comment on peut faire pour que cette partie soit visible pour la démo ? Voilà la façon dont je travaille sur Cursor."
Sur la configuration des règles derrière le repo : "On a une politique avec plein de règles qu'on a mises en place. Quand je fais un changement, soit on overwrite ces règles, soit on vient ajuster avec des call flows si quelque chose arrive, fais ça."
Sur le design system pixel perfect : "Il est plugué à Cursor. Quand je veux faire de l'interface, je lui demande de rester dans le cadre du design system. Il lui arrive d'halluciner un peu. Il va faire des boutons carrés alors qu'on a des boutons ronds partout. Je lui dis : tu es sorti de ton design system."
5. Pas un titre, une posture
Pantéa formule sa vision des nouveaux profils avec une thèse claire : le trio PM-designer-développeur n'est pas en train de disparaître. Il est en train de se fondre dans un profil commun le product builder.
"Quand un designer est aussi PM et peut aussi faire un peu de tech, ça devient un product builder. Quelqu'un qui construit des produits et qui est capable de shipper directement en production."
Chez Beside, ses PM font des interfaces directement dans Claude. Ils lui demandent son avis. "Je prends leur branche, je fais mon feedback. Ils ont l'ownership de leur produit, on va tester. Et comme on va tester rapidement, on ne va pas se focaliser sur qui a raison."
Le risque de cette approche : qui est garant de la vision quand tout le monde construit ? Sa réponse : les fondateurs portent la vision et les North Stars. Des profils seniors prennent des ownerships sur des sujets précis, créent des roadmaps, et délivrent avec l'équipe.
"Le titre n'a vraiment plus beaucoup d'importance. Je ne pense vraiment pas que les métiers disparaissent. Je pense qu'ils vont se mélanger."
6. Être juste UX/UI ne suffit plus. Ni juste dev, ni juste PM.
Pantéa est directe. "Une IA fait un écran propre en trente secondes. Être juste UX ou UI seul ne suffit vraiment plus." Elle compare avec ce que le métier a déjà vécu : à l'époque de La Fourchette, il y avait des personnes séparées pour l'UX et l'UI. Le product designer a absorbé les deux. "On est un step plus loin maintenant."
Même diagnostic pour le code : "Savoir coder ne suffit plus. Pousser du code, une IA peut le faire aussi." Pour le PM : "Une IA peut te faire un business plan, une roadmap, des hypothèses."
Ce qui reste irremplaçable selon Pantéa : le jugement, le goût, la connaissance des utilisateurs. Et surtout, la casquette business stratégique. "Qu'est-ce qu'on veut solutionner ? Quels problèmes on veut solutionner ? Comment tu définis le succès ?"
"Si tu as bien scopé ton sujet, avec une problématique claire, des hypothèses claires, une recherche claire, tu le balances à ton IA, il va t'aider à construire. Mais il ne va pas pouvoir deviner les problèmes. Faire ta grosse analyse, c'est toi qui vas le faire sur Amplitude, en parlant à tes utilisateurs, en regardant les métriques, en testant, en prenant des risques."
Quatre conseils concrets : sortir de Figma et travailler dans le produit réel. Lire le code pas tout, mais comprendre. Parler aux clients régulièrement, toujours. Et apprendre le business.
"L'IA ne remplacera pas les designers. Elle exposera surtout ceux qui confondent écran et design. Parce que design, ça vient de l'anglais, ça veut dire concevoir. On est des builders."
7. Apprivoiser ses outils et accepter de ne pas tout comprendre
Sur Cursor et le code : "Au début, on peut se dire, oh là là, je ne comprends rien à ce qui se passe. En fait, vous n'avez pas besoin de tout comprendre. Vous devez savoir quoi et comment demander. Et ensuite, juger ce que l'IA produit."
Sur les bugs et les limites : "Souvent, ce n'est pas la faute de l'agent, c'est la faute de la personne qui prompte. Vraiment." Sur les parties back-end : "Je suis complètement perdue là-dessus. Si j'ai besoin, j'ai toujours un copain dans l'équipe qui peut m'aider. Mais la plupart du temps, je suis autonome à débuguer ce qui ne fonctionne pas comme je l'avais prompté."
Sur la vitesse actuelle : "Il y a six mois, rappelez-vous de ce qu'on n'était pas capable de faire. Je ne sais pas si vous vous rendez compte du bouleversement qu'on a en très peu de temps. Évidemment, aujourd'hui, ce n'est pas parfait. Et demain, ça le sera encore plus."
Sur la recherche utilisateur qui ne disparaît pas : "Je ship une feature toutes les semaines. J'appelle mes utilisateurs dès qu'ils ont une nouvelle feature dans les mains. Parler aux clients, c'est un sujet qui n'arrêtera jamais."