Quand construire devient bon marché, décider devient cher

Toutes les équipes produit l’ont senti cette année : une fonctionnalité qui prenait un sprint prend un après-midi, et le backlog se vide plus vite que quiconque ne peut le remplir de choses qui valent la peine d’être construites. Cet article répond à ce que cela fait au rôle produit, à partir des mesures publiées jusqu’ici, avec l’échantillon et la date à côté de chaque chiffre.

Construire est-il vraiment moins cher ?

Oui, et le chiffre honnête est plus petit que la sensation. Le rapport DORA 2025, publié par Google Cloud le 23 septembre 2025 auprès de près de 5 000 répondants, trouve 90 % d’usage de l’IA au travail et, pour la première fois, une relation positive entre l’adoption de l’IA et le débit de livraison. Le même rapport trouve que l’adoption de l’IA garde une relation négative avec la stabilité des livraisons : plus de changements partent, et plus d’entre eux cassent.

L’enquête de Lenny Rachitsky et Noam Segal auprès de 1 750 product managers, développeurs, designers et fondateurs, publiée le 23 décembre 2025, a trouvé que plus de la moitié gagnent au moins une demi-journée par semaine sur leurs tâches les plus importantes. La même enquête a trouvé que 92,4 % signalent au moins un inconvénient significatif des outils. Les deux chiffres sont vrais en même temps, et une équipe qui ne cite que le premier planifie sur une fiction.

Pourquoi le gain paraît-il plus grand qu’il n’est ?

Parce que ceux qui le vivent se trompent dans la même direction. METR a mené un essai contrôlé randomisé, publié le 10 juillet 2025 : seize développeurs open source expérimentés, 246 tâches réelles issues de leurs propres dépôts, chaque tâche tirée au sort pour autoriser ou interdire les outils d’IA. Avec l’IA autorisée, les développeurs ont mis 19 % plus de temps. Avant l’étude, ils avaient prévu un gain de 24 %, et après avoir vécu le ralentissement, ils croyaient encore que l’IA les avait rendus 20 % plus rapides.

Seize développeurs forment un petit échantillon et les outils étaient des modèles de début 2025, ce que les auteurs écrivent eux-mêmes. Ce que l’essai établit est plus étroit et plus utile qu’un verdict sur l’IA : la vitesse perçue est un instrument peu fiable. Une équipe produit qui veut connaître sa vraie vélocité doit la mesurer — délai de livraison, taux d’échec des changements, les quatre indicateurs DORA — outils activés et désactivés.

Où se déplace le goulot ?

Vers le jugement. Quand la production cesse d’être la limite, trois décisions fixent le résultat, et aucune ne va plus vite avec un assistant de code.

• Quoi construire : quel problème, pour qui, à quelle fréquence il survient, et ce que coûte d’attendre trois mois.
• Comment vous saurez que cela a marché : le chiffre qui doit bouger, écrit avant la construction, avec la date à laquelle il sera lu.
• Si un utilisateur peut s’y fier : pour une fonction IA, les cas où elle peut répondre, les cas où elle doit refuser, et la façon dont la confiance est affichée.

Marty Cagan écrivait le 30 décembre 2024 que « the PM role becomes more essential but also more difficult with generative AI-powered products, not less », en réservant son enthousiasme à la combinaison de « someone with very strong judgement » et des outils. Teresa Torres a dit la même chose côté discovery en avril 2026 : « Building is very cheap now. That doesn’t mean we should build every idea we have. » Tous deux décrivent un rôle dont la ressource rare est le jugement sur ce qui mérite d’exister.

Que fait une équipe produit de tout cela ?

Trois gestes pratiques en découlent, et chacun coûte peu à démarrer.

• Mesurez la vélocité outils activés et désactivés pendant un mois, et lisez le taux d’échec des changements à côté du débit. Le constat de DORA sur la stabilité est celui que la plupart des équipes découvrent tard.
• Écrivez la décision avant la construction : une page avec le problème, les options sur la table, ce qui a été écarté et ce qui doit être vrai dans deux mois.
• Consacrez les heures libérées à la discovery et aux évals. Un entretien synthétisé par une personne puis par un modèle, et une fonction IA spécifiée en cas de test avant le premier prompt, voilà où va désormais la semaine.

La méthode de priorisation est décrite dans décider quoi construire ensuite. Pour un fondateur au runway limité, la même logique décide ce que la première construction doit prouver, et la page pour les fondateurs expose cet ordre.

Comment le studio travaille avec cela

La réponse de Torn Studio est un modèle de livraison : une personne tient le rôle produit et construit avec des outils d’IA, de sorte qu’une décision prise le lundi est dans le code la même semaine. Le coût est dit aussi clairement que le gain. La semaine d’une personne est la capacité, et une équipe qui a besoin de trois rôles produit en parallèle a intérêt à les recruter. Le Product Management est tarifé par mission, avec le périmètre défini à l’avance et le prix fixé avant le début du travail.