Les signaux de la semaine
Veille du 24 au 30 août 2026 · par ton agent de veille
21 contenus identifiés cette semaine
12 retenus pour leur pertinence, 9 écartés.
- YouTube
- Newsletters
- Podcasts
Les designers et PMs les plus efficaces sont ceux qui ont accès à la codebase
Le message clé
Le tournant n'est pas que l'IA écrive du code. C'est que designers et PMs lisent désormais la codebase eux-mêmes. Une question sur une règle métier trouve sa réponse en trente secondes, en local — plus dans un ticket de 2023, plus en piquant trente minutes à un dev.
Ce qui se passe en ce moment
Romain Bachna (Parlons Design) le fait depuis trois ou quatre mois : il clone le repo de son produit, ouvre un agent de code dessus, et lui demande sous quelles conditions un élément s'affiche ou comment se calcule un chiffre du dashboard. Même bascule chez Léo Guillon : depuis le 17 août, la commande /design génère les variantes dans la session qui porte déjà le code. L'outil vient au travail, plus l'inverse.
- Un setup en trois gestes, et rien à casser. Tu clones le dépôt principal depuis GitHub ou GitLab, comme le ferait un développeur. Tu installes un agent de code — Claude Code, Codex ou Cursor — et tu lui indiques ce dossier comme répertoire de travail. C'est tout. Comme tu travailles sur une copie posée sur ta machine, même une modification accidentelle n'affecte personne d'autre que toi, et un pull en un clic suffit à repasser sur la version à jour du code.
- Le vrai obstacle est politique, pas technique. Romain Bachna décrit trois catégories d'entreprises : celles où les accès sont déjà ouverts, celles — la majorité — où donner le code à un non-développeur ne se fait simplement pas par habitude mais où personne n'a jamais posé la question, et celles où la tech « protège le code comme un bébé ». Dans la plupart des sociétés de moins de 300 personnes, il suffit de demander. La formulation qui débloque : présenter la démarche comme un test en lecture seule, jamais comme une envie de toucher au code.
- Le gain n'est pas le temps, c'est la nature de la conversation. Léo Guillon a testé /design, la commande de Claude Code qui génère des maquettes d'interface, sur un écran de portail client : trois directions produites, puis un arbitrage avec son Product Owner en une vingtaine de minutes. Ce qui l'a marqué n'est pas la vitesse, mais le sujet dont ils ont enfin pu parler. Au lieu de se demander si l'écran « ressemble à quelque chose », ils ont discuté du modèle mental qu'ils voulaient installer chez l'utilisateur — parce que comparer trois partis pris rend la question concrète.
On va estimer notre design par rapport à ce qu'on connaît, par rapport à ce qu'on croit connaître, mais sans avoir une base existante.
Ce que tu peux faire en tant que PM
Ouvre la codebase de ton produit cette semaine et pose-lui les trois questions que tu contournes depuis des mois
- Clone le repo principal de ton produit depuis GitHub ou GitLab, comme le ferait un dev. Prérequis : un accès en lecture — si tu ne l'as pas, demande-le au lead tech en le présentant comme un POC en lecture seule, jamais en édition.
- Installe un agent de code et pointe-le sur ce dossier : Claude Code (abonnement payant), ChatGPT Codex ou Cursor (plans gratuits). Utilise en priorité la solution déjà payée par ta boîte, pour la privacy. Setup : 30 minutes.
- Pose tes trois questions en attente dès la première session : sous quelles conditions cet élément s'affiche, comment ce chiffre du dashboard est calculé, quels sont tous les types d'activité du feed. Refais un pull avant chaque série de questions, sinon tu lis du code périmé.
- Enchaîne avec /design dans Claude Code, mais seulement après le cadrage et la recherche : donne-lui le design system, les états de compte à couvrir et tes insights utilisateurs, puis demande trois directions contrastées — dense, guidée, orientée donnée — plutôt qu'une maquette. Attends-toi à une grosse conso de tokens : c'est une research preview.
- Compte, sur deux semaines, le nombre de questions résolues seul contre le nombre d'allers-retours dev évités. Si le ratio tient, tu as ton argumentaire pour ouvrir l'accès codebase au reste des designers et des PMs — sinon, garde le POC en solo et retente au prochain hackathon.
Passer de la productivité IA personnelle à celle de l'équipe
Le message clé
Ton gain de productivité IA est resté personnel. Les idées ne coûtent plus rien — un prototype en quelques heures — donc le goulot a déménagé : il est passé de la créativité vers le contexte partagé, là où les décisions se prennent.
Ce qui se passe en ce moment
Elena O'Mahony, CPO de Mural, avance une thèse à contre-courant : la collaboration visuelle a disparu à l'ère de l'IA. Chacun passe ses journées seul dans sa fenêtre de chat, en texte ou en dictée, puis repart partager un document — et le contexte se perd exactement là où la décision se prend. Sa question résume l'enjeu : est-ce que je joue au même jeu que toi, est-ce que je sais d'où tu es parti, et puis-je te rattraper assez vite pour qu'on décide ensemble ?
- « Qu'a-t-on appris ? », jamais « qu'a-t-on livré ? » C'est la seule question qu'elle pose à ses équipes lors de leur revue mensuelle, et son critère est net : si la décision n'a pas changé, si l'on pense encore comme le mois dernier, c'est qu'on n'a pas collecté la bonne information.
- Aucun outil de ta pile ne conserve le pourquoi d'une décision. Les OKR disent ce qui est planifié, Slack porte la conversation de l'instant, Notion, Jira ou Linear gardent les décisions actées. Reste une page blanche : comment la décision a été prise, et pourquoi. Les notes de réunion arrivent après et n'en conservent qu'un résumé.
- Les grands déploiements ne marchent pas : commence par une petite équipe. Elle est catégorique sur ce point. Plutôt que d'imposer un changement à toute l'organisation d'un coup, elle recommande de trouver quelques volontaires, de les laisser essayer, et de s'appuyer sur eux pour convaincre les autres.
- Rationner les tokens produit exactement le mauvais comportement. Chez ses grands comptes, un employé arrivé à 80 % de son prototype voit ses tokens coupés et va en quémander à ses collègues. Sa règle de conduite est ailleurs : poser d'abord une couche de mesure, car ce n'est pas parce qu'on peut le faire avec de l'IA qu'il faut le faire avec de l'IA.
Because AI is so solo player mode, it's really hard to see people work out in public to get the ideas of how to move forward.
Ce que tu peux faire en tant que PM
Pousse ton équipe à se partager ses apprentissages, plutôt que de travailler chacun seul avec l'IA
- Remplace ton prochain document de stratégie par un prototype cliquable — deux heures maximum — et présente-le explicitement comme une direction à explorer, pas comme une spécification à livrer telle quelle.
- Cartographie les décisions de ton dernier trimestre sur un espace partagé, avec trois colonnes : la décision, le pourquoi, ce qu'on a appris depuis. Prérequis : 45 minutes et l'historique de tes comptes rendus.
- Change la question d'ouverture de ta revue mensuelle : demande « qu'a-t-on appris ce mois-ci ? » avant « qu'a-t-on livré ? », et note si la réponse modifie une décision.
- Identifie ton forward deployed engineer caché — la personne du juridique, du support ou de la finance qui a déjà automatisé son propre process — et programme-lui une démo de 20 minutes devant ton équipe produit.
- Mesure avant de généraliser : liste les usages où l'IA n'apporte rien, pose une couche de mesure sur la consommation, et décide en fin de mois lesquels tu coupes.
La troisième ère de l'IA : l'essor des collègues IA persistants
Le message clé
Première ère, le chat : tu poses une question, tu refermes l'onglet. Deuxième ère, l'agent : tu délègues une tâche, tu attends le résultat. La troisième arrive, et c'est celle du collègue persistant — celui qui garde son contexte entre deux tâches.
Ce qui se passe en ce moment
Tara Seshan, qui dirige Codex et ChatGPT Work chez OpenAI, met un nom sur le basculement en cours. Après le chat, après les agents qu'on invoque pour une tâche, vient le collègue persistant. La différence n'est pas une question de puissance mais de continuité : un agent qui repart de zéro à chaque session ne peut pas accumuler ce qu'un collègue accumule — les habitudes de l'équipe, les décisions passées, ce qui a déjà été essayé. Le reste de l'entretien porte moins sur les modèles que sur ce que ce basculement exige de toi.
- Un collègue garde le fil, un agent le perd. C'est toute la nuance du mot « persistant ». L'agent qu'on invoque traite une tâche, rend un résultat, puis oublie. Le collègue persistant, lui, conserve son contexte d'une fois sur l'autre : tu lui donnes ton avis, il repart travailler, et tu fais le point avec lui quand tu veux, comme avec quelqu'un de ton équipe.
- Construis pour les modèles de dans deux à trois mois. Sa formule est tranchée : tu échoues si tu construis pour l'état actuel des modèles, et tu échoues tout autant si tu construis pour ce qu'ils seront dans un an. Les deux erreurs se valent, et le seul horizon tenable est cette fenêtre courte.
- Ton travail devient de barrer, pas de ramer. Les agents rament ; toi, tu tiens le cap. Et le niveau auquel tu interviens ne cesse de monter — de la ligne de code à l'objectif, puis au-delà. Ce qui reste humain, c'est de décider la direction, y compris quand la donnée ne tranche pas.
- Un agent privé d'accès à tes systèmes ne sert pas à grand-chose. Sa comparaison est nette : un collègue qu'on embauche puis qu'on enferme dans une pièce, sans accès aux documents ni à la messagerie de l'entreprise, serait inutile. Ce qui rend un agent efficace n'est donc pas seulement son raisonnement, c'est l'accès aux endroits où vivent réellement les données.
- Le vrai goulot n'est plus la capacité, c'est l'ambition. Les capacités ont explosé ; ce qui reste difficile est d'élargir sa propre idée de ce qui est faisable en peu de temps. D'où la question qu'elle emprunte à Tyler Cowen et qu'elle pose à ses équipes : quelle serait la version dix fois plus ambitieuse de ce que tu proposes ?
You fail if you build for where the models are now. You fail if you build for where you think the models will be in a year. Both outcomes are equally wrong.
Ce que tu peux faire en tant que PM
Fais passer un agent du statut d'outil qu'on relance à celui de collègue qui reste
- Choisis une tâche récurrente que tu relances aujourd'hui à la main — un suivi hebdomadaire, une revue de tickets — et confie-la au même agent pendant deux semaines sans repartir de zéro à chaque fois.
- Donne-lui les accès dont il a besoin pour être utile : tes documents, tes comptes rendus, tes outils de suivi. Sans cela tu emploies un collègue que tu as enfermé dans une pièce vide.
- Fixe ton horizon à deux ou trois mois. Liste ce que tu renonces à construire parce que le modèle ne sait pas encore le faire, note la date, et réexamine la liste dans huit semaines.
- Monte d'un cran ton niveau d'intervention. Sur ta prochaine tâche déléguée, donne un objectif plutôt qu'une suite d'instructions, et note où l'agent a réellement eu besoin de toi.
- Pose la question qui élève l'ambition à ta prochaine revue d'équipe : quelle serait la version dix fois plus ambitieuse de ce qu'on propose ? Compte combien de fois la réponse change le plan.