Les signaux de la semaine
Veille du 12 au 18 juillet 2026 · par ton agent de veille
39 contenus identifiés cette semaine
13 retenus pour leur pertinence, 26 écartés.
- YouTube
- Newsletters
- Podcasts
Voici 5 tutos Claude pour automatiser ton quotidien de Product
Le message clé
Le Ticket sort d'un coup 5 démos de PMs qui montre comment ils se servent de l'IA pour automatiser leurs tâches et gagner en efficacité.
- Sources :
- Le Ticket — Julie Prieur (Poppins)
- Le Ticket — orchestrer ses 1ers agents
- Le Ticket — analyser ses feedbacks avec l'IA
- Le Ticket — prototypes Claude Code et Lovable
- Le Ticket — Élodie Gueho (Gens de Confiance)
Ce qui se passe en ce moment
Le Ticket a publié cette semaine 5 démos filmées pendant le Grand Rattrapage : personal OS, agents de delivery, analyse de feedback, prototypage, veille concurrentielle. Cinq façons concrètes d'utiliser l'IA dans ton quotidien de PM, chacune à copier directement. Retrouve ci-dessus les liens pour aller voir les démos en détails, et sinon voici un résumé de ce qu'on a appris pour chacune :
- Créer son personal OS et son Chief of Staff IA avec Claude Code : Julie Prieur (CPO, Poppins) a construit trois skills concrètes — Avistore qui rédige des réponses aux avis clients en respectant des garde-fous stricts (elle valide avant publication) ; OBG qui résume ses appels d'onboarding parents à partir du transcript, anonymise les données RGPD et poste un récap sur Slack après validation ; et Jarvis, son agent bras droit qui scanne chaque matin agenda, mails et Slack pour proposer des arbitrages adaptés à son niveau d'énergie du jour.
- Orchestrer ses 1ers agents dans Claude et Dust pour automatiser sa delivery et sa rédaction de tickets Jira : la démo montre comment enchaîner plusieurs agents pour transformer une conversation en tickets Jira prêts à assigner — utile dès que tu perds du temps à reformater tes specs en tâches.
- Analyser ses feedback utilisateurs avec l'IA pour enrichir sa discovery : comment faire lire à l'IA un gros volume de retours utilisateurs pour en sortir des patterns exploitables, plutôt que de les parcourir un par un à la main.
- Créer ses premiers prototypes avec Claude Code et Lovable : le pas-à-pas pour passer d'une idée à un prototype cliquable en une session, sans écrire une ligne de code toi-même.
- Faire sa veille concurrentielle avec Claude Cowork (sans y passer des heures) : Élodie Gueho (Lead PM, Gens de Confiance) fait tourner sa veille automatiquement, postée sur Slack et rangée dans Notion — le modèle à copier si ta veille concurrentielle est encore un rituel manuel du vendredi.
En fait, j'ai toute ma tête rangée dans des tiroirs qui sont accessibles à Claude et c'est ça qui change tout pour moi.
Ce que tu peux faire en tant que PM
Les conseils de Julie pour prendre en main l'IA et automatiser des choses
- Commence très simple, un MVP, puis itère : une phrase comme « Je voudrais que tu me challenges en tant que CPO, que proposes-tu ? » suffit pour créer ton premier agent.
- Parle naturellement à Claude — la dictée vocale donne plus de contexte qu'un texte tapé — et demande-lui de détailler étape par étape.
- Stocke tout sur Git : un repo privé pour tes données personnelles, un repo partagé avec l'équipe pour les skills et agents communs. Les données restent en local, donc attention à la perte d'ordinateur — Julie utilise Git comme cloud.
- Compte environ 100 €/mois pour l'abonnement Claude — Julie n'a pas encore optimisé sa consommation de tokens, mais recommande de le faire dès le départ.
- Pars de tes propres douleurs pour créer une skill (ex. « je galère à copier-coller mes avis ») et laisse Claude te poser des questions pour challenger le besoin avant de coder quoi que ce soit.
Tout le monde devient Product Builder dans l'équipe produit — même les exécutifs et les CPOs.
Le message clé
Ce n'est pas qu'un mouvement chez les PMs et designers : partout, y compris chez les dirigeants produit, le rôle se redéfinit autour d'une capacité — prototyper et shipper soi-même — plutôt que seulement décider et déléguer.
- Sources :
- The Skip — Nikhil Singhal
- Product School — Saral Jain (Snap)
- Maestro — webinar Product Builder
Ce qui se passe en ce moment
Trois sources cette semaine, trois métiers différents, un seul constat : le rôle de Product Builder — celui qui prototype et ship lui-même, plutôt que de décrire ce qu'il veut à quelqu'un d'autre — grimpe les échelons. Il ne se limite plus aux PMs juniors ou aux designers : il touche maintenant les dirigeants produit eux-mêmes. Voici comment chacune de ces trois sources illustre ce même glissement.
- The Skip (Nikhil Singhal) : chez les dirigeants produit, il observe un basculement clair — ceux qui codent, prototypent et montent des démos eux-mêmes prennent l'avantage sur ceux qui se contentent de décider et de déléguer. Le craft redevient une compétence de haut niveau, pas juste un point de départ de carrière qu'on quitte en montant en grade.
- Product School (Saral Jain, SVP Engineering chez Snap) : chez Snap, ce glissement est déjà institutionnalisé — PMs et designers envoient directement du code en prod, avec un agent (Casper) qui construit le premier prototype depuis Slack ou Jira. Concret : plus de 90 % du code publié est relu par l'IA en moins de 5 minutes, ce qui rend ce shipping direct possible sans casser le produit.
- Maestro (Maxime) : la formation « Product Builder » qu'il anime confirme la tendance côté marché — de plus en plus de profils, PMs comme dirigeants, veulent apprendre à construire eux-mêmes plutôt que rédiger des specs. Son conseil concret : se spécialiser sur un seul outil pour gagner en réflexes, plutôt que d'en survoler dix.
The bottleneck is not Figma mockups. The bottleneck is we just build the prototype and then show the prototype and the best idea wins.
Ce que tu peux faire en tant que PM
Remets la main dans le craft cette semaine
- Construis un projet perso de bout en bout avec un outil de build (Claude Code, Lovable…) — pas une démo, un truc que quelqu'un utilise.
- Documente-le publiquement : un post LinkedIn ou un README avec le problème, la stack, le résultat.
- Identifie dans ta boîte un prototype que tu peux shipper toi-même au lieu de l'écrire en spec.
- Évalue ta prochaine étape de carrière à l'aune de ce que tu sais construire, pas seulement de ce que tu sais décider.
- Mesure dans 3 mois : nombre d'artefacts construits (pas écrits) que tu peux montrer en entretien.
Des designers qui craft dans le code directement, sans utiliser Figma. Voici comment cette startup tourne à 100% avec Claude
Le message clé
Chez Nobase, le design system vit dans le code : les designers ouvrent leurs propres pull requests et shippent des features eux-mêmes — sans repasser par Figma, sans attendre un développeur.
Ce qui se passe en ce moment
Le truc dingue chez Nobase : ils ont tué le handoff design → dev. Les designers ne touchent plus Figma pour l'interface — ils travaillent directement dans le code avec Claude, qui génère composants et mises en page en s'appuyant sur leur design system. Plus de maquettes à transmettre, plus d'attente : le designer ship lui-même, via une pull request, comme un développeur. Mais shipper soi-même sans développeur pour relire ne marche que si la méthode derrière est solide — voici comment Maxime et son équipe l'ont construite.
- Le design system comme fondation : investi dès l'early stage (l'équipe ne compte qu'une quinzaine de personnes), documenté dans un storybook vivant — une bibliothèque en ligne qui référence chaque composant de l'interface avec ses variantes — chaque composant, chaque token a une source unique que Claude peut lire avant de générer du code.
- Qui a le droit de shipper quoi : le rédacteur de contenu modifie les textes, le product designer ajuste espacements et coins arrondis, le designer système retouche directement les composants dans la doc — chacun sur son périmètre, pas de libre accès à toute la codebase.
- La garde-fou, c'est la CI, pas un humain : chaque pull request passe par une série de tests automatiques avant de merger. C'est ce qui permet d'ouvrir le droit de shipper à des non-développeurs sans qu'une erreur de design casse la prod.
- Ce qu'ils ont appris : au début, tout le monde pouvait toucher à tout — ça a cassé des choses. La version qui marche, c'est un périmètre clair par rôle plus la CI comme filet. Sans ces deux garde-fous, le code-first tourne vite au chaos.
- Le geste devenu banal : récupérer un composant directement depuis le produit en ligne (pas depuis une maquette) et ajuster son espacement à la main, en pull request — plus besoin de rouvrir Figma.
On sait que demain une feature, on peut la développer en quelques heures, versus à l'époque quelques jours.
Ce que tu peux faire en tant que PM
Reproduis la méthode de Maxime chez toi
- Documente ton design system dans un storybook (une bibliothèque en ligne qui référence chaque composant avec ses variantes) — c'est la base que Claude doit pouvoir lire avant de générer du code.
- Définis qui a le droit de toucher à quoi : contenu, tokens, composants — un périmètre clair par rôle, pas un accès libre à toute la codebase.
- Mets en place une CI (les tests automatiques qui tournent à chaque changement) avant d'ouvrir le droit de shipper à des non-développeurs — c'est elle qui remplace la relecture humaine.
- Lance un pilote : une pull request de contenu ou de token, ouverte par un designer, protégée par cette CI.
- Élargis le workflow à un rôle de plus une fois que le pilote tourne sans casse — composants, puis mises en page complètes.