Les signaux de la semaine
Veille du 21 au 27 juin 2026 · par ton agent de veille
33 contenus identifiés cette semaine
11 retenus pour leur pertinence, 22 écartés.
- YouTube
- Newsletters
- Podcasts
Devenir une équipe AI-native : ce n'est pas juste avoir les bons outils
Le message clé
L'adoption des outils IA est partout. Mais dans la plupart des équipes, les process n'ont pourtant pas vraiment changés. Des entreprises ont mis en place des actions pour justement améliorer cela. Amplitude a tout arrêté pendant une semaine — 700 personnes, zéro réunion — pour forcer le changement. Sylvain Tirel (ex VP AI, Brevo) a mis des agents sur 30% des tickets support. Voilà ce que ça donne, concrètement.
- Sources :
- Product Thinking — State of AI in Product 2026 (survey 309 leaders)
- Clef de Voûte — 3 boîtes, 3 stades de maturité IA
- The Product Crew — Ex VP AI Brevo : réorganiser sa boîte pour l'IA
- Le Ticket — Amplitude AI Week : 700 employés, 1 semaine d'arrêt total
Ce qui se passe en ce moment
Plusieurs sources cette semaine convergent vers le même constat : les outils IA se répandent vite, mais dans la plupart des équipes, la façon de travailler n'a pas suivi. Ce qu'on retient : devenir AI-native n'est pas une question d'outils — c'est une question de conditions. Certaines boîtes ont commencé à les créer. Voici comment.
- Product Thinking (survey, 309 leaders) — l'état des lieux 2026 en une ligne : « The tools have changed, but the work did not. » La plupart des équipes ont Cursor ou Copilot. Très peu ont changé comment elles décident, priorisent ou fonctionnent ensemble.
- Amplitude a testé le format radical : une semaine sans activité normale, tout le monde en mode « Build AI ». +300 compétences développées, et leur équipe parle d'un avant/après réel. Pour un PM, le signal : le changement ne vient pas tout seul — il faut créer les conditions.
- Sylvain Tirel (ex VP AI, Brevo) : les agents couvrent 30% des tickets support. Sa leçon directe — « les agents échouent dès qu'il y a de l'indécision ou du flou dans les processus. » Avant de déléguer à un agent, clarifie ta propre procédure.
- Clef de Voûte passe en revue 3 boîtes françaises à des stades différents : la PME qui commence, la startup qui restructure, le scale-up qui reconstruit. Le constat : on ne saute pas d'étape. Commencer par l'étape 3 sans avoir fait l'étape 1, c'est la recette du projet qui rate.
- Ce que ça change pour toi : si ton équipe n'a pas encore eu de bloc « Build Time » protégé, c'est probablement le seul levier à activer cette semaine — pas un plan de transformation, juste 2h bloquées pour expérimenter un cas concret.
The tools have changed, but the work did not.
Ce que tu peux faire en tant que PM
Organise un atelier d'exploration IA avec ton équipe produit
- Audite d'abord tes process et rituels : liste tous les process, rituels, workflows de ton équipe — delivery, discovery, design, go-to-market, rétrospectives. Pour chacun, document comment ils sont réalisés aujourd'hui et combien de temps cela prends.
- Bloque une journée atelier avec toute l'équipe produit. Divise-la en groupes de 2-3 personnes, chacun avec un process assigné. L'objectif va être ensuite de voir l'améliorer grâce a l'IA (etape suivante).
- Donne un cadre clair à chaque groupe : « Comment est-ce qu'on pourrait automatiser ou améliorer la qualité et la vitesse d'exécution de ce process grâce à l'IA ? » Limite à 2h par groupe pour forcer la priorisation. Il faut expérimenter avec des outils et agents tels que Claude Cowork. Et connecter les outils à Claude grâce aux MCPs. Les participants doivent réellement expérimenter, tenter d'automatiser des process de bout a bout.
- Partage les résultats en plénière : chaque groupe présente ce qu'il a testé, ce qui a marché, ce qui n'a pas marché. L'objectif n'est pas d'avoir tout automatisé à 100%. Mais d'avoir pu identifier des parties du process qui peuvent être exécutés plus rapidement, et avec qualité.
- Priorise un chantier à lancer dans les deux semaines qui suivent l'atelier — sinon l'élan retombe. Un seul process transformé concrètement vaut mieux que dix idées en attente. Désigne un leader qui aura pour but de continuer a donner du rythme a cette initiative.
L'IA a accéléré le dev. Les PMs sont devenus le bottleneck.
Le message clé
L'IA a multiplié par 8 la productivité des ingénieurs chez Anthropic. Résultat inattendu : ce n'est plus le code qui ralentit — c'est la qualité des décisions produit. Les PMs sont devenus le nouveau goulot d'étranglement. Voici 5 façons de ne plus l'être.
- Sources :
- Lenny's Podcast — Fiona Fung : What happens after coding is solved?
- Mind the Product — Emily Tate : A deep dive into the state of product in 2026
Ce qui se passe en ce moment
La productivité des ingénieurs explose avec l'IA — plusieurs signaux cette semaine le confirment chiffres à l'appui. Et quand coder n'est plus le goulot d'étranglement, que la production va de plus en plus vite, c'est désormais a l'équipe produit de devoir tenir le rythme, tout en gardant une bonne qualité de décisions.
- Fiona Fung (Anthropic) : les ingénieurs Anthropic produisent en moyenne 8× plus de code par trimestre qu'en 2025. Ce n'est pas une projection, c'est une mesure interne. « Coding is no longer the bottleneck. »
- Emily Tate (VP Product) formule la menace clairement : « Building is not the bottleneck, and now deciding what to build becomes the bottleneck. » Le PM qui exécute vite n'a plus d'avantage si tout le monde peut faire pareil.
- Ce que ça veut dire concrètement : ce que l'IA n'arrive pas a reproduire ou automatiser, sont des tâches subtitles et délicates tels que le product taste, design taste, etc. Créer une bonne roadmap, ce n'est pas simplement exécuter les demandes les plus fréquentes des utilisateurs. C'est faire des choix en s'appuyant sur trois éléments : les données du marché, les retours utilisateurs et l'alignement avec les parties prenantes en interne.
- Le signe que tu es sur la bonne piste : tu passes plus de temps à parler à des utilisateurs qu'à écrire des specs ou faire des meetings de cadrage technique. Les meilleurs PMs en 2026 ne deviennent pas des ingénieurs IA — ils deviennent de meilleurs détectives du problème.
If your only moat is that your product is AI, you're going to be replaced by anyone with Lovable in their living rooms.
Ce que tu peux faire en tant que PM
5 façons pour un PM de ne plus être le bottleneck à l'ère de l'IA
- Passer du « comment construire » au « quoi construire » : quand le code n'est plus rare, la ressource critique devient la qualité des décisions de roadmap. Automatise tes tâches répétitives pour passer plus de temps sur le « what » — et moins dans des réunions sur le « how ».
- Obtenir plus de données de conversations utilisateurs : ton meilleur avantage compétitif est une compréhension fine des besoins et des frustrations. Centralise tous tes feedbacks (Intercom, call recordings, tickets support) via des MCPs dans Claude — demande-lui d'identifier les tendances, problèmes récurrents et opportunités.
- Donner plus d'ownership aux équipes delivery : au lieu de détailler chaque feature, définis un problème, un résultat attendu et des métriques de succès. Les équipes — et les agents IA — peuvent explorer plusieurs solutions sans attendre specs ou maquettes officielles.
- Automatiser les tâches à faible valeur : rédaction de specs, comptes-rendus de réunion, tri de tickets — délègue tout ça à des agents IA. Ton temps doit aller aux décisions qui demandent du jugement : comprendre les utilisateurs, arbitrer les priorités, définir la stratégie.
- Partager le contexte à ton équipe de manière proactive : connecte tes outils de documentation (Notion, Google Docs) à Slack. Un agent IA peut filtrer les informations importantes, les résumer et les diffuser automatiquement — une meilleure circulation du contexte permet aux équipes d'avancer de manière plus autonome.
L'expérimentation produit doit changer à l'ère de l'IA
Le message clé
Elena Verna ouvre avec une mise en garde directe : « I bet your 2022 experimentation playbook is obsolete. » Elle n'a pas tort. Quatre choses ont changé depuis que tu as appris à expérimenter — et si tu fais encore du A/B test sur des variantes de boutons dans un produit IA, tu mesures le mauvais truc.
Ce qui se passe en ce moment
L'expérimentation produit repose sur des fondamentaux solides — A/B tests, significativité statistique, itérations courtes. Mais ces fondamentaux ont été construits pour un monde sans IA. Elena Verna pose la question inconfortable cette semaine : est-ce qu'ils tiennent encore ? Ce qu'on retient : quatre choses ont changé, et elles remettent les bases en question. Voici lesquelles.
- Le premier shift — les interfaces s'effacent : quand une chatbox remplace plusieurs pages, il n'y a plus de « page » à tester. L'unité d'expérimentation se déplace vers les comportements et les workflows — pas les éléments visuels.
- Le deuxième shift — le code sort vite : les cycles qui duraient des semaines durent maintenant des heures. La fenêtre de test raccourcit, et les résultats se contaminent plus vite entre variantes. Tes critères de significativité statistique méritent d'être revus.
- Le troisième shift — l'IA personnalise déjà : tester « titre A vs. titre B » a moins de sens quand l'IA adapte le copy pour chaque utilisateur en temps réel. Les tests de copy deviennent moins pertinents. Les tests de workflow, eux, restent valides.
- Le quatrième shift — chaque requête coûte : contrairement à une page web, chaque interaction avec un agent a un coût variable. Une expé qui augmente le volume de requêtes peut coûter plus qu'elle ne rapporte. La logique d'optimisation du revenu change.
- Ce que ça change pour toi : si ton prochain sprint inclut des A/B tests sur du copy ou des éléments UI dans un produit IA, questionne leur utilité avant de les lancer. Le bon test en 2026 porte sur le workflow, pas sur le titre.
I bet your 2022 experimentation playbook is obsolete.
Ce que tu peux faire en tant que PM
Remettre à jour son playbook d'expérimentation
- Regarde tes 3 dernières expérimentations — testaient-elles des éléments visuels ou des comportements utilisateurs ? La réponse te dira où tu en es.
- Identifie une hypothèse dans ton backlog qui porte sur un workflow ou un modèle d'usage — c'est la prochaine expérimentation à prioriser.
- Calcule le coût d'inférence moyen d'un utilisateur sur une semaine dans ton produit — tu as besoin de ce chiffre avant de lancer des expés de pricing.
- Lis l'article complet d'Elena Verna pour les 4 shifts détaillés avec des frameworks applicables directement.