Les signaux de la semaine
Veille du 7 au 13 septembre 2026 · par ton agent de veille
22 contenus identifiés cette semaine
14 retenus pour leur pertinence, 8 écartés.
- YouTube
- Newsletters
- Podcasts
Construire ne coûte presque plus rien. Choisir devient le vrai métier.
Le message clé
Quand produire une fonctionnalité devient quasi gratuit, la question « est-ce qu'on sait le faire » disparaît et il ne reste que « est-ce qu'il fallait le faire ». Deux intervenants nomment la compétence qui prend le relais, et elle s'apprend.
- Sources :
- Jonathan Widawski (Maze) — Le French Product
- Ravi Mehta (ex-CPO Tinder), résumé par Le Ticket
Ce qui se passe en ce moment
Jonathan Widawski dirige Maze, une plateforme de recherche utilisateur. Ravi Mehta a été directeur produit de Tinder. Le premier décrit le volume qui arrive, le second la compétence qui permet d'y faire face.
- Le chiffre qui pose le problème : on va produire vingt fois plus, et l'essentiel sera à côté. La formule de Widawski est brutale — au moment où chacun peut tout construire, la seule chose qui compte devient ce qu'on construit. Il rappelle au passage l'arbitrage que les équipes font depuis vingt ans : entre livrer quelque chose de faux tout de suite et ralentir pour apprendre, elles choisissent toujours de livrer. Multiplier la capacité de production sans changer cet arbitrage ne fait que multiplier les erreurs.
- Le goût n'est pas un don, c'est une compétence de tri — et ça change tout. Ravi Mehta le définit comme le fait de regarder l'ensemble des possibles et de décider lequel est le bon. La conséquence est contre-intuitive : l'essentiel du travail se joue avant la décision, dans le fait de connaître l'étendue des options disponibles. Quelqu'un qui tranche vite sans avoir exploré n'a pas du goût, il a des réflexes.
- Le vrai danger n'est pas que l'IA fasse le travail, c'est qu'elle prenne les décisions. Mehta sépare deux choses qu'on confond : savoir ce qu'on veut créer, et savoir le fabriquer. L'IA effondre la seconde, ce qui rend la première décisive. Mais si on lui laisse aussi les choix de conception, on cesse d'exercer la compétence qui nous restait — et on ne la développe plus. Continuer à décider soi-même devient donc un entraînement, pas une coquetterie.
Au moment où tout le monde peut construire n'importe quoi, la seule chose qui compte, c'est ce que tu construis.
Ce que tu peux faire en tant que PM
Reprends une décision produit récente et vérifie que tu avais exploré avant de trancher
- Choisis une décision que tu as prise vite cette semaine et écris les options que tu avais réellement en tête au moment de trancher. Si la liste tient en deux lignes, tu n'as pas choisi, tu as pris la première solution venue.
- Élargis l'éventail avant de décider, pas après. Fais-toi produire dix variantes d'une fonctionnalité en cours, même mauvaises : le but n'est pas d'en retenir une, c'est de voir le terrain que tu ignorais.
- Sépare explicitement les deux questions dans tes revues : sait-on fabriquer ça, et fallait-il le fabriquer ? Traiter la seconde en premier, à l'oral, évite de valider par défaut ce qui a déjà été codé.
- Note ce que tu n'as pas construit et pourquoi. C'est la seule trace du travail de tri, et la seule façon de montrer sa valeur à quelqu'un qui ne voit que les livraisons.
- Garde au moins une décision de conception par semaine que tu prends toi-même, sans suggestion automatique. C'est ce qui entretient la compétence plutôt que de la déléguer.
Les designers inversent le process : prototype d'abord (macro UX), maquettes ensuite
Le message clé
L'ordre de travail s'inverse : on ne part plus de la maquette pour finir par le développement. On part d'un prototype qui fonctionne, et l'outil de maquettage n'intervient plus qu'à la fin, pour livrer ce qui a été validé.
Ce qui se passe en ce moment
Léo Guillon raconte un projet où ce renversement a eu lieu pour de bon. Timothé Frin, lui, a passé la conférence annuelle de Figma à poser la même question à des dizaines de designers. Les deux récits se rejoignent.
- Le prototype remplace le brief, et ça supprime une étape entière de traduction. Sur le projet de Guillon, le responsable produit et les développeurs étaient arrivés avec leurs propres prototypes déjà construits. Résultat : plus besoin d'expliquer comment les écrans s'enchaînent ni de demander aux gens de se projeter dans une interaction qui n'existe pas. Les parties prenantes cliquent, parcourent, et réagissent sur du concret dès la première réunion.
- Le travail du designer se déplace vers la logique du parcours, pas l'apparence. Au premier coup d'œil le prototype était bon ; à l'usage, le parcours de commande était découpé à l'excès, presque une question par page. Le vrai travail a consisté à regrouper ce qui relevait d'une même décision — pas à changer les couleurs ou à poser de meilleurs composants. C'est exactement la compétence que le prototypage automatique ne remplace pas.
- Sur le terrain, la frontière entre les métiers s'efface et crée une vraie tension. Les designers interrogés à Config décrivent des semaines devenues des jours, et surtout un changement de nature : on ne livre plus l'image d'un produit, on livre le produit. Mais quand les responsables produit prototypent eux-mêmes et que les designers touchent au code, chacun se demande ce qui lui reste en propre. Aucun des interviewés ne prétend que c'est réglé.
Montrer quelque chose à quelqu'un est bien plus simple que le lui raconter. Ça a aidé tout le monde dans l'entreprise à exposer ses idées plus vite.
Ce que tu peux faire en tant que PM
Fais valider ton prochain parcours sur un prototype cliquable avant d'ouvrir Figma
- Reconstruis ton système de composants en code avant de commencer, même partiellement. C'est ce qui a permis à l'équipe de Guillon de ne pas repartir de zéro visuellement et de rester cohérente dès le premier prototype.
- Fais réagir les parties prenantes sur un prototype, jamais sur une maquette figée. Prévois des cycles courts : on modifie une fonctionnalité, le responsable produit la présente aux utilisateurs, on ajuste pour la version suivante.
- Accepte les défauts visuels à ce stade. L'objectif est de valider les parcours, pas le rendu — traiter les deux en même temps ramène la discussion sur les couleurs et fait perdre le sujet.
- Distingue les parties prenantes des utilisateurs dans ton plan de test : les premières portent une vision stratégique ou technique, les seconds se retrouveront devant l'écran. Ce ne sont presque jamais les mêmes personnes.
- Garde Figma pour le livrable final, une fois les parcours tranchés. C'est le renversement à tester une fois : si ça marche sur un projet, tu sauras si ça tient sur les suivants.
Claude, Dust : ils montent en puissance quand tu leur donnes le contexte de tes outils
Le message clé
Un agent sans accès à tes données répond depuis sa culture générale, pas depuis ton produit. Ce qui le rend utile, ce sont les connecteurs vers tes outils — et ce qui le rend acceptable en entreprise, ce sont les limites posées autour.
Ce qui se passe en ce moment
Romain Bachna détaille le setup minimum d'un agent pour un designer ou un responsable produit. Chez Stripe, Sherrod a construit l'agent interne utilisé par plus de 86 % de l'entreprise. Même mécanique, deux échelles.
- Les trois connecteurs à brancher en premier, dans cet ordre. D'abord l'outil de mesure d'audience, pour que l'agent réponde sur tes chiffres réels et non sur des généralités. Ensuite le dépôt de retours utilisateurs, qui lui donne la matière qualitative éparpillée entre plusieurs outils. Enfin les espaces où vit la connaissance métier — documentation, suivi de tickets, présentations. Le risque reste faible car ces accès sont en lecture, et l'agent ne modifie rien sans autorisation explicite.
- Le garde-fou qui rend l'agent acceptable en entreprise : la politique d'outils par projet. Chez Stripe, un espace de travail définit qui accède à quoi et avec quel modèle. L'exemple donné est parlant : quelqu'un des ressources humaines manipule des données sensibles, on ne veut ni qu'il s'en prive, ni que l'agent les recopie dans un document ouvert à toute l'entreprise. La réponse n'est pas d'interdire les outils, c'est de restreindre lesquels sont disponibles selon le contexte.
- La hiérarchie à trois niveaux qui évite les réponses fausses sur les données. Leur agent cherche d'abord dans les rapports existants, puis dans la couche de métriques validées, et seulement en dernier recours écrit sa propre requête. Un agent sait répondre, mais il n'a aucune idée de savoir si c'était la bonne requête ou la bonne table — cette cascade, écrite par des analystes, est ce qui transforme une réponse plausible en réponse fiable.
Les agents sont très créatifs quand il s'agit de faire tomber ton infrastructure. Ils amplifient tous tes modes de défaillance existants.
Ce que tu peux faire en tant que PM
Branche tes trois connecteurs cette semaine, puis pose une limite avant d'élargir
- Connecte ton outil de mesure d'audience en premier — c'est celui qui change le plus vite la qualité des réponses. Prérequis : les mêmes droits de lecture que ceux dont tu disposes déjà toi-même.
- Ajoute ton dépôt de retours utilisateurs, quel que soit l'outil. C'est la matière que personne n'a le temps de relire et que l'agent peut traverser en entier.
- Écris ta cascade de sources avant de poser une question chiffrée : où chercher d'abord, où chercher ensuite, et quand s'autoriser une requête inédite. Sans cet ordre, tu obtiendras une réponse plausible impossible à vérifier.
- Définis un périmètre par type de travail, pas par personne : ce à quoi l'agent accède quand il traite un sujet sensible, et ce qu'il ne doit jamais pouvoir écrire ailleurs.
- Vérifie que ton entrepôt de données tient la charge avant d'ouvrir l'accès à toute l'équipe : dans le doute, un agent interroge en force brute plutôt qu'avec parcimonie.