Les signaux de la semaine
Veille du 15 au 21 juin 2026 · par ton agent de veille
30 contenus identifiés cette semaine
12 retenus pour leur pertinence, 18 écartés.
- YouTube
- Newsletters
- Podcasts
Les équipes produit AI-first triplent leur vélocité et impact
Le message clé
Trois entreprises très différentes — une plateforme d'automatisation, une startup EdTech, une scale-up IT — montrent la même chose : reconstruire l'organisation autour de l'IA produit autant avec moitié moins de monde.
- Sources :
- Inside Make's AI operating model: 50% revenue growth, same headcount (Clef de Voûte)
- Une équipe produit qui shippe avec l'IA : ce que ça veut dire vraiment (Just a Click)
- Ce CEO a triplé ses opérations sans recruter (The Product Crew)
Ce qui se passe en ce moment
Depuis six mois, un même mot revient dans les post-mortems des équipes produit qui ont vraiment changé leur façon de travailler : reconstruction. Pas adoption, pas intégration — reconstruction. Trois cas très différents cette semaine (SaaS B2B, EdTech, logistique) montrent des chiffres qui n'auraient pas eu de sens il y a deux ans : +50 % de revenus à effectifs constants, une plateforme livrée seul en 5 semaines, un taux de commandes parfaites passé de 75 % à 90 % avec la même équipe de 2. La vraie question n'est pas « quelle techno IA doit-on embarquer ? » — c'est « quel process peut-on améliorer ou automatiser avec l'IA ? » Ceux qui partent du process avancent deux fois plus vite que ceux qui partent de l'outil.
- La leçon de Fabian Veit (Make.com) : ses clients qui échouent commencent par chercher « le bon outil IA ». Ceux qui réussissent commencent par se demander « quel process on reconstruit en premier ? » — même outil, résultat radicalement différent.
- Florian Bruniaux (EdTech) : une plateforme de soutien scolaire (4ᵉ – terminale) construite seul en 5 semaines avec Claude Code. Pas de réunion de spec, pas de co-équipier — il écrivait les exigences, l'agent construisait, il validait. Le modèle : PM-éditeur plutôt que PM-rédacteur.
- Fleet (logistique) : 40 – 45 personnes, 30 – 40 M€ de CA. L'équipe supply chain (2 personnes) a doublé ses volumes à effectifs constants. Résultat concret : le taux de commandes parfaites passe de 75 % à 90 %, ce qui a directement réduit les coûts SAV. Les deux tiers du code de Fleet sont aujourd'hui écrits par l'IA.
- Comment distinguer accélération et reconstruction : si ton projet IA ressemble à « on a ajouté un assistant à nos outils existants », tu accélères. Si tu as supprimé un processus entier et redessiné qui fait quoi, tu reconstruis. Le gap de résultats entre les deux, c'est ce que montrent ces trois cas.
Le plus grand piège que je vois, c'est que les entreprises commencent par chercher des outils IA au lieu d'identifier leurs processus internes à améliorer.
Ce que tu peux faire en tant que PM
Identifie et automatise un process cette semaine
- Liste tes 3 processus les plus chronophages (rédaction de specs, backlog grooming, rédaction de tickets, compte-rendus de réunion, reporting…). Choisis celui qui consomme le plus d'heures sans apporter de valeur différenciante.
- Teste-le avec Claude (claude.ai) en mode Project : colle ton contexte produit dans les instructions système (stack, personas, objectifs), puis demande à Claude de faire le travail à ta place. Note ce qu'il produit bien — et ce qu'il rate.
- Si le process implique du code ou de la config : essaie Claude Code (terminal) ou Cursor. Florian Bruniaux a livré une plateforme EdTech entière en 5 semaines seul avec Claude Code — commence par une feature ou un script, pas par le produit entier.
- Définis un indicateur avant de lancer — temps économisé par semaine, nombre de tickets rédigés à la main, qualité des outputs mesurée sur 5 points. Sans mesure, tu ne sauras pas si tu as vraiment gagné quelque chose.
- Bilan dans 2 semaines : le process tourne-t-il avec 30 % de ton temps initial ? Si oui, passe au suivant. Si non, le problème est souvent dans le contexte donné à l'IA — enrichis le Project et relance.
Former les PMs en IA : la vraie compétence, c'est de savoir bien juger — pas juste aller plus vite
Le message clé
Les PMs qui maîtrisent vraiment les outils IA ne font pas les mêmes choses plus vite — ils font des choses différentes, et leur métier se déplace vers le jugement et l'évaluation.
Ce qui se passe en ce moment
Jeff Gothelf le dit sans détour : former les PMs aux outils IA, c'est la partie facile. La partie difficile — celle que presque aucune formation n'adresse vraiment — c'est d'apprendre à juger ce que l'IA produit. Parce que la vraie promesse de l'IA pour un PM, ce n'est pas de rédiger des specs deux fois plus vite. C'est d'apprendre plus vite, d'itérer plus vite, de détecter plus tôt ce qui ne marche pas. Un PM qui produit deux fois plus vite des outputs médiocres n'a pas progressé — il a accéléré ses erreurs. Le déplacement qui compte : le PM cesse d'être le rédacteur. Il devient l'arbitre.
- Le changement de rôle concret : avant, tu produisais — tu rédigeais la spec, tu structurais le backlog, tu formulais les critères d'acceptance. Maintenant, l'IA produit. Toi, tu évalues. Et évaluer, c'est une compétence différente : ça demande de savoir ce qui manque dans un texte qui semble correct, et de formuler un jugement que l'IA ne peut pas avoir seule.
- Le piège que Gothelf identifie : la plupart des équipes se concentrent sur la première partie — livrer plus vite. Elles oublient le reste de la boucle : sentir comment les clients répondent vraiment, et changer ce qu'on fait ensuite. L'IA peut amplifier cette boucle d'apprentissage — mais seulement si le PM sait l'utiliser pour apprendre, pas juste pour produire.
- Ce que « bien juger » veut dire en pratique : quand l'IA te rend une spec, tu dois pouvoir répondre à trois questions — est-ce que le problème est bien posé ? Est-ce que le contexte business implicite est là ? Est-ce que les critères de succès sont mesurables ? Si tu ne peux pas répondre à ces questions, tu ne peux pas évaluer l'output. Tu valides à l'aveugle.
- La conséquence si l'évaluation est mauvaise : tu vas plus vite dans la mauvaise direction. Un PM qui délègue sans savoir juger produit des specs IA en 40 minutes — et embarque toute l'équipe dans la mauvaise direction deux fois plus vite qu'avant. La vitesse sans jugement est un amplificateur d'erreurs.
Tu livres quelque chose de petit, tu sens comment les clients y répondent vraiment, et tu t'adaptes en changeant ce que tu fais ensuite. L'IA peut amplifier ces boucles d'apprentissage à des niveaux inédits. Le problème, c'est que la plupart des organisations se concentrent sur la première partie — la livraison — et ignorent la valeur de l'IA dans le reste de la boucle d'apprentissage.
Ce que tu peux faire en tant que PM
Entraîne ton jugement sur l'IA cette semaine
- Prends une spec ou un document produit que tu as rédigé cette semaine et refais-le avec l'IA. Mesure le temps — puis liste précisément ce que l'IA a raté ou mal compris.
- Ce que l'IA a raté, c'est ta valeur ajoutée réelle. Écris-la noir sur blanc — c'est le profil de PM que l'IA ne remplace pas encore dans ton contexte.
- Teste ton jugement : sur le dernier output IA que tu as validé, pose-toi trois questions — le problème était-il bien posé ? Le contexte business implicite était-il là ? Les critères de succès étaient-ils mesurables ? Si tu ne pouvais pas répondre, tu as validé à l'aveugle.
- Fixe une règle simple pour le mois : une tâche de rédaction déléguée à l'IA chaque semaine, avec une évaluation écrite du résultat (ce qui était bon, ce qui manquait). Après 4 semaines, tu sais où est ta vraie valeur — et tu as entraîné ton jugement.
La qualité des features IA s'améliore grâce à la technique des evals
Le message clé
Avant d'écrire une spec, définis tes critères de succès — et laisse le modèle travailler. Les evals remplacent le PRD dans les équipes produit IA qui jouent en avance.
Ce qui se passe en ce moment
Imagine que tu viens d'améliorer le prompt de ta feature IA. Comment tu sais que c'est vraiment mieux ? En général : on teste à la main, ça semble mieux, on shippe. Et parfois, trois jours après, on réalise qu'on a cassé autre chose. Les équipes les plus avancées ont trouvé une réponse : les evals (pour évaluations). Une eval, c'est un mini-test automatisé sur un cas réel. Exemple : un utilisateur écrit « annule ma commande » — tu définis que l'IA doit appeler cancel_order() et ne pas appeler refund(). Pass ou fail. Pas de « c'est globalement bien ». Quand tu en as cinquante, tu pilotes la qualité de ton produit IA comme un ingénieur pilote ses tests — et le modèle peut s'améliorer tout seul pendant que tu travailles sur autre chose.
- Pourquoi c'est critique : sans evals, tu itères sur des impressions. Chaque amélioration de prompt pourrait régresser un autre comportement sans que tu le voies. Ankur Goyal (CEO, Braintrust) : « De bonnes evals, c'est ce qui transforme l'agent d'un exécutant en problem-solver. »
- L'erreur la plus fréquente : écrire le prompt avant de définir les critères de succès. Résultat : on optimise pour que ça « semble bon » — sans jamais savoir si c'est vraiment bon.
- Comment créer ses premières evals en 30 minutes : prends 5 vraies conversations utilisateur. Pour chacune, écris ce que l'agent aurait dû faire. Formule-le comme un critère pass/fail. Tu viens de créer ta première suite d'evals — pas besoin d'outil spécialisé pour commencer.
- L'avantage côté PM : les evals te donnent un langage commun avec l'ingénierie. Au lieu de dire « améliore la qualité des réponses » (flou), tu dis « passe de 42/50 à 47/50 sur ces cas de test » (pilotable). C'est une spec que tout le monde peut mesurer.
La ligne des agents continue de monter. Avec de bonnes evals, le modèle peut résoudre les problèmes de façon créative et autonome.
Ce que tu peux faire en tant que PM
Crée tes premières evals cette semaine
- Choisis une feature IA que ton équipe utilise déjà — quelque chose de concret avec des cas d'usage réels.
- Collecte 5 conversations ou inputs réels d'utilisateurs sur cette feature (logs, support, tests manuels).
- Pour chaque cas, écris ce que l'IA aurait dû faire — de façon précise et binaire : « l'agent appelle X », « la réponse contient Y », « la réponse n'inclut pas Z ».
- Lance ces 5 tests sur la version actuelle et note les résultats. Tu viens de créer ta baseline — tu peux maintenant mesurer si une modification est une amélioration ou une régression.
- Regarde l'épisode de Ankur Goyal (CEO Braintrust) sur How-I-AI pour aller plus loin sur le framework complet.
- 🎯