Les signaux de la semaine
Veille du 21 au 27 septembre 2026 · par ton agent de veille
33 contenus identifiés cette semaine
14 retenus pour leur pertinence, 19 écartés.
- YouTube
- Newsletters
- Podcasts
Les PMs d'OpenAI ne font plus de maquettes : ils implémentent directement dans le produit
Le message clé
Chez OpenAI, un responsable produit qui n'a jamais été développeur ouvre une branche et code sa proposition au lieu de livrer une maquette. Ce n'est pas la maquette qui disparaît, c'est l'étape de traduction entre l'intention et le produit.
Ce qui se passe en ce moment
Katia Gil Guzman travaille dans l'équipe Developer Experience d'OpenAI. Sophie est product designer chez Zefir, une plateforme immobilière. Deux contextes opposés, deux réponses différentes à la même bascule.
- Ce qui a changé n'est pas l'outil, c'est la qualité de ce qui arrive. Katia Gil Guzman se souvient d'un designer qui lui avait envoyé une proposition de code touchant à tous les modèles de données. Inutilisable. Aujourd'hui : elle reçoit une proposition d'un responsable produit qui n'a jamais été ingénieur, et elle est parfaite. Ce qui a permis ça, dit-elle, c'est d'avoir mis les règles de jugement dans le dépôt.
- La condition technique tient en un fichier d'entrée et des compétences par tâche. Leur dépôt contient un fichier d'instructions qui ne fait pas tout le travail : il dit surtout « si tu dois faire telle tâche, va regarder tel endroit », et renvoie vers une compétence écrite pour ce cas précis : ajouter un guide, ajouter un cas d'usage, ajouter une démonstration. C'est ce qui rend le résultat prévisible.
- Chez Zefir, l'IA remplace le séminaire de conception, pas l'outil de maquettage. L'équipe compte deux designers et n'a pas les moyens de réunir tout le monde pour une semaine d'idéation. Sophie lui donne ses schémas, ses données et son cadrage à la voix, vérifie qu'il a compris en lui faisant résumer, puis lui demande d'écrire le prompt qui générera les esquisses. Elle retourne ensuite dans Figma pour construire, en piochant dans ce qui est sorti.
Au lieu de me donner un Figma avec des exemples de ce à quoi ça pourrait ressembler, il a directement implémenté la nouvelle interface dans le code.
Passe à l'action
C'est la bascule de ce sujet, à ton échelle : au lieu d'une maquette qu'il faudra traduire, tu fais coder la fonctionnalité dans ton propre produit, avec son vrai design system. Tes parties prenantes réagissent à quelque chose de réel et ajustent le prototype eux-mêmes par un lien. Tu repars avec une version validée, pas avec des retours à interpréter.
Voir le coursVoici comment cette entreprise corrige 60 % des problèmes utilisateurs en 24 h
Le message clé
Quand des agents écrivent le code, ce qui ralentit une équipe n'est plus la construction : c'est de savoir quoi construire. Chez Ramp, toute la chaîne part donc d'un agent qui lit l'ensemble des retours clients et désigne les problèmes à traiter en premier.
Ce qui se passe en ce moment
Geoff Charles dirige le produit de Ramp, un logiciel américain de gestion des dépenses d'entreprise. Au Lenny's Summit, il a déroulé la chaîne que son équipe a bâtie pour passer d'une plainte client à une correction en ligne, étape par étape.
- Le code n'est plus ce qui freine : le frein s'est déplacé vers l'équipe produit. Chez Ramp, 75 % des modifications de code sont écrites par leur propre agent, dont un millier le mois dernier par des non-ingénieurs. Geoff Charles compare ça aux arrêts au stand en Formule 1 : changer quatre pneus prenait 67 secondes dans les années 1950, 1,8 aujourd'hui, en supprimant un point de blocage après l'autre. Une fois le code accéléré, le blocage suivant est en amont : comprendre ce que les clients demandent.
- Les retours clients sont trop éparpillés pour être lus, par un humain comme par une IA. Ils vivent dans les enregistrements d'appels commerciaux, le support, les sondages, les emails furieux envoyés à la direction. Même un modèle capable de lire un million de mots n'absorbe pas 0,5 % des appels de Ramp. L'équipe a donc construit un agent qui collecte toutes ces sources, regroupe les plaintes qui parlent du même problème et connaît le produit. Chaque équipe y accède par Slack, par un tableau de bord, et même par un podcast quotidien de verbatims clients.
- Relié au reste de la chaîne, un retour client peut devenir une correction en une journée. Un deuxième agent croise ces retours avec la recherche utilisateur et les données d'usage pour cerner le vrai besoin, puis produit un prototype dans le système de design maison. Pour les petits problèmes, l'IA fait tout le trajet : elle retrouve le ticket existant, dédoublonne, compte les occurrences, classe, code et teste, et un humain valide dans Slack. Résultat : 60 % des problèmes d'expérience signalés par un client, un commercial ou le support sont corrigés en moins de 24 heures.
Ça ne veut pas dire arrêter de parler aux clients. Ça veut dire savoir exactement à quels clients parler, parce que chaque donnée est traçable.
Passe à l'action
Chez Ramp, toute la chaîne part d'un agent qui lit les retours clients. Ce cours te fait construire cette première brique, à ton échelle : chaque feedback posté dans Slack par tes commerciaux ou tes CSM atterrit dans une base Notion, résumé et taggé par partie du produit, et une routine Claude tient à jour un dashboard que ton équipe consulte. Tu sais quoi construire en premier, avec les verbatims pour le prouver.
Voir le coursL'interface zombie : pourquoi tes écrans générés se ressemblent tous, et comment l'éviter
Le message clé
Un modèle donne la réponse la plus probable, c'est-à-dire ce qui a déjà marché ailleurs. Appliqué à l'interface, ça produit des écrans corrects, polis et interchangeables, que Katie Dill compare aux immeubles d'après-guerre copiés sans intention.
- Sources :
- Katie Dill (Stripe), Lenny's Summit
Ce qui se passe en ce moment
Katie Dill dirige le design chez Stripe. Son analogie est architecturale : après 1945, le style moderniste a été copié sans la pensée qui l'avait produit, jusqu'à couvrir les villes de bâtiments interchangeables. Elle voit le même mécanisme à l'œuvre aujourd'hui.
- Le premier écueil : le modèle te donne le probable, pas le spécifique. Il sait ce qui est populaire et ce qui a fonctionné ; il est beaucoup moins bon pour ce qui est propre à ta marque et au contexte de ton utilisateur. Son exemple : une page dont on jurerait qu'elle vend un logiciel, alors qu'il s'agit d'un restaurant coréen. Correcte, sans aucun caractère.
- Le deuxième, qu'elle appelle la tentation du fini. L'IA donne très vite l'impression que c'est terminé, souvent trop tôt. Elle l'illustre par son burrito au micro-ondes : à peine mangeable, mais la vitesse d'exécution lui fait passer sur des défauts sérieux. Un rendu poli masque les vraies questions : est-ce que ça résout le problème, est-ce que ça différencie ?
- Le troisième est le plus insidieux : ce qui est facile à produire devient jetable. Comme le travail coûte peu, on cesse d'assumer ses décisions et de penser au long terme, à commencer par qui maintiendra tout ça. Sa parade tient dans les détails qui prouvent qu'un humain a fait attention : la date affichée dans l'icône de l'agenda, une animation qui donne vie à l'interface.
On passe la moitié de nos heures éveillées devant des écrans. On veut des logiciels dont on sent que quelqu'un s'est soucié de nous.
Passe à l'action
Pour sortir de l'écran probable, il faut savoir ce que font les autres et ce qui te distingue. Ce cours branche un agent sur une librairie d'écrans réels : en une minute, des dizaines d'écrans sur ton sujet, les constantes du secteur que personne ne repère à l'œil, et une liste à reprendre ou à éviter, avec l'écran qui justifie chaque point. Tu arrives devant l'outil de génération avec un point de vue, pas avec la moyenne du marché.
Voir le cours