Que devient le modèle produit quand construire ne coûte presque rien ?

Sur la discovery : tester les idées par des prototypes avant d'engager l'ingénierie, parce que beaucoup d'idées ne valent pas d'être construites. Pour Aakash Gupta et Rohan Varma, toute l'organisation produit classique découle en plus d'une rareté, celle de l'ingénieur. C'est ce postulat que l'IA entame, pour une partie des tâches.

Le product operating model popularisé par Marty Cagan et le Silicon Valley Product Group (SVPG) confie à des équipes produit durables la responsabilité d'un résultat. Il s'appuie sur la discovery : tester les idées par des prototypes, bien moins chers qu'un produit construit, avant d'engager l'ingénierie. Le livre TRANSFORMED, paru en 2024, en donne la version systématisée pour les entreprises qui changent de modèle.

La lecture de Gupta et Varma

Aakash Gupta et Rohan Varma vont plus loin : pour eux, toute l'organisation produit classique découle d'une croyance, écrire du code est difficile et l'ingénieur est la ressource la plus rare. D'où les couches de coordination autour des ingénieurs et les points de contrôle défensifs avant de construire. À notre lecture, rien dans cette organisation ne prévoit qu'on construise cinq variantes d'une fonctionnalité pour en jeter quatre.

Ce modèle a sorti des organisations entières du mode projet, où l'informatique exécutait des demandes, pour les amener vers des équipes produit durables, chacune responsable d'un problème à résoudre. Cagan lui-même annonçait en février 2025, dans A Vision For Product Teams, que l'équipe produit type passerait dans les trois à dix ans de 8 personnes (6 ingénieurs, un PM, un designer) à 3.

Le premier signal chiffré

Un des premiers signaux chiffrés date de 2022. Dans un essai contrôlé de GitHub sur 95 développeurs indépendants recrutés en ligne, écrire un serveur web en JavaScript a pris en moyenne 1 h 11 avec Copilot contre 2 h 41 sans. L'essai porte sur une seule tâche, et l'écart de taux de réussite (78 % contre 70 %) n'est pas significatif selon l'article de recherche.

Notre lecture : la prémisse du code cher perd de sa force sur un éventail de tâches qui s'élargit, et la rareté se déplace vers la capacité à choisir les bons problèmes, à piloter les agents et à concevoir les évaluations.

Parce que se tromper coûte moins cher. Quand une mauvaise piste coûte une demi-heure d'agent au lieu de deux semaines d'ingénierie, écrivent Aakash Gupta et Rohan Varma, on peut construire d'abord et évaluer ensuite. Dans les organisations établies, à notre lecture, ces phases rentreront plutôt dans des boucles plus courtes.

La thèse vient de The AI Product Operating Model, d'Aakash Gupta et Rohan Varma (17/06/2026). Rohan Varma est chef de produit de Codex chez OpenAI, après avoir été l'un des premiers PM de Cursor : l'un des auteurs travaille pour un des exemples cités. Selon eux, quand construire la mauvaise chose coûte trente minutes de temps d'agent au lieu de deux semaines d'ingénierie, on peut se permettre de construire d'abord.

Ils avancent deux exemples, sans mesure publiée. Une tâche de dix heures d'ingénieur prendrait dix minutes avec Codex ou Claude Code. Et lors d'un hackathon de l'équipe Codex avec une grande entreprise non nommée, un chantier de modernisation estimé à dix ingénieurs sur douze mois a été mené par deux ingénieurs en trois jours. L'exemple vient d'un hackathon : l'ordre de grandeur vaut pour des tâches bien bornées.

Ce qui change dans le cycle

Le modèle classique traite le fait de construire d'abord comme un luxe, puisque chaque cycle consomme des semaines de travail rare : c'est ce qui justifie discovery, PRD et business case préalables. Quand construire devient bon marché, la question devient celle que formulent Gupta et Varma : on a eu l'idée, on l'a construite, faut-il la livrer ? Jeremy Daly notait dès octobre 2025 que prototyper était devenu « presque sans effort » pour un PM, avec Claude Code, Codex, Cursor ou Warp.

Plusieurs étapes du cycle se recomposent, selon nos sources et à notre lecture :

• La revue de code se déplace vers la revue de ce que fait le logiciel (comportement, performance, sécurité), quand les agents vérifient déjà une partie de leur propre travail. C'est notre lecture.
• La planification lourde perd de son utilité quand une mauvaise orientation coûte une demi-heure d'agent, selon Gupta et Varma.
• La cadence s'accélère : chez Anthropic, Cat Wu, responsable produit de Claude Code, décrit dans le podcast de Lenny (23/04/2026) des délais passés de mois à semaines, puis à jours, et conseille de commencer par fixer des objectifs clairs plutôt que d'aligner des roadmaps sur plusieurs trimestres.
• Le PRD change de contenu : dans son cours chez Product Faculty, Rohan Varma enseigne un « AI PRD » qui fixe les risques, les garde-fous et les métriques de succès avant d'écrire du code (programme du cours).

Gupta et Varma décrivent une logique qui s'effondre. Notre lecture : dans les organisations établies, ces phases rentreront plutôt dans des boucles plus courtes et mieux outillées. L'enjeu, pour nous, est de reconfigurer revue de code, sprints et PRD autour de la qualité de ce que le produit fait.

Sur la coordination, avancent Gupta et Varma : selon eux, 30 à 50 % de l'effort d'une équipe classique sert à se synchroniser. Les entreprises nées avec l'IA réduisent ces couches avec de petites équipes très outillées, comme celle de Codex chez OpenAI, environ 40 personnes dont un seul PM.

Gupta et Varma estiment, sans mesure publiée, qu'entre 30 et 50 % de l'effort total d'une équipe traditionnelle est de la pure coordination : les couches de managers, de chefs de projet techniques et de scrum masters autour des ingénieurs, les synchronisations, la planification des sprints. Quand construire coûte cher, cette coordination est rationnelle. Quand un petit groupe peut expérimenter vite, elle devient un frein.

Chez Anthropic et chez OpenAI

Chez Anthropic, Cat Wu décrit des designers qui font aussi le travail de PM et livrent du code, et des fonctionnalités testées en interne avant d'être lancées en préversion (podcast de Lenny, 23/04/2026). Un résumé de l'épisode, publié sur X par Ole Lehmann, en a tiré une règle : n'importe qui prototype, et l'outil n'est poli que s'il sert encore le lendemain et le surlendemain. Nous n'avons pas retrouvé cette règle dans les propos de Cat Wu.

L'équipe Codex d'OpenAI compte environ 40 personnes, dont un seul PM et deux designers, selon Engineering Leadership (22/02/2026). Elle se sert de Codex pour planifier, accueillir les nouveaux, relire le code, tester et prioriser ; l'outil installe le poste d'un nouvel arrivant et lui explique la base de code. Gupta et Varma lui prêtent dix à douze surfaces produit, là où une entreprise classique aurait, selon eux, une équipe de quinze à vingt personnes par surface.

Les cas extrêmes

Les cas extrêmes se lisent comme des bornes. Medvi, une société de télésanté qui vend des médicaments amaigrissants, a réalisé 401 millions de dollars de ventes en 2025 avec deux salariés, le fondateur Matthew Gallagher et son frère, plus des prestataires, selon le New York Times, qui dit avoir consulté ses comptes. Elle externalise ses couches médicales et réglementaires.

Le cas a ses zones d'ombre : le 20/02/2026, la FDA lui a adressé une lettre d'avertissement pour des allégations trompeuses sur ses médicaments composés. Notre lecture : ce cas montre que la frontière de ce qu'un très petit groupe peut faire a bougé.

Une façon de construire un produit d'IA en le pilotant par ses évaluations, les « évals » : des tests qui mesurent la qualité des réponses d'un système dont la sortie varie. Vercel les compare aux tests de bout en bout du logiciel classique ; Red Hat raconte comment une équipe les a branchées sur son intégration continue.

Un système d'IA ne répond pas deux fois la même chose : les tests classiques ne suffisent plus. Vercel (17/10/2024) compare les évals aux tests de bout en bout pour l'IA et les autres systèmes probabilistes, et en distingue trois sortes :

• par du code, pour les critères objectifs et un retour rapide ;
• par un humain, pour les critères subjectifs comme la clarté ;
• par un autre modèle, qui passe à l'échelle mais peut être moins fiable qu'un humain.

Red Hat raconte le 23/03/2026 comment une équipe a évalué un agent de support informatique en huit étapes, des tests manuels à la surveillance continue, avec une étape d'intégration dans la chaîne d'intégration et de déploiement continus (CI/CD) pour éviter les régressions.

Des objectifs de score

Notre lecture : dans une équipe qui travaille ainsi, l'objectif se formule en score à atteindre sur un jeu d'évals, et une démo montre l'évolution des scores et de l'usage. Un tableau de scores parle moins à un comité de direction qu'une roadmap de fonctionnalités. Passer à l'eval-driven se prépare donc autant côté gouvernance et reporting que côté outillage.

Ce mode de travail suppose aussi des outils de déploiement, des évaluations automatisées et un suivi assez industrialisés pour que lancer une expérience coûte peu. À notre avis, c'est un prérequis facile à oublier quand on prend Anthropic pour modèle.

La spécification change de nature

Pour Jeremy Daly, l'IA peut générer des suites de tests qui deviennent des « PRD vivants », une représentation mesurable et vérifiable des exigences. Ben den Blanken, consultant néerlandais sur les outils Microsoft, plaide en octobre 2025 pour un modèle opératoire propre aux agents : des propriétaires, des garde-fous, des prompts versionnés comme du code, une supervision humaine, des règles sur les données.

Les équipes rétrécissent, les rôles s'élargissent et la hiérarchie s'aplatit, résume la consultante Allie K. Miller. Boris Cherny, créateur de Claude Code, propose cinq archétypes (Prototyper, Builder, Sweeper, Grower, Maintainer) : des façons de contribuer selon le stade du produit, que beaucoup de gens cumulent à deux ou trois.

C'est le versant le plus concret pour une direction produit ou une DRH. Dans sa newsletter du 15/07/2026, Allie K. Miller décrit trois mouvements :

• le travail d'un pod complet fait par deux ou trois personnes à l'aise avec le code qui travaillent avec des agents ;
• des rôles définis par le travail et le résultat qu'on porte ;
• des couches de management intermédiaire qui s'amincissent.

C'est une affirmation de consultante, sans données propres.

La référence reste la two-pizza team d'Amazon : une équipe assez petite pour être nourrie avec deux pizzas, afin de limiter les lignes de communication. À notre lecture, l'IA déplace cette limite en réduisant le coût de coordination par personne.

Les cinq archétypes de Boris Cherny

Le 28/06/2026, Boris Cherny écrivait sur X que l'ingénierie, le produit, le design et la data science fondent en un nouveau type de rôle, et décrivait cinq archétypes :

• Prototyper : propose des idées neuves en rafale, dont la plupart ne sortent jamais ;
• Builder : transforme vite un prototype en produit de qualité production ;
• Sweeper : nettoie l'interface, simplifie le code et le système, retire des fonctionnalités, optimise ;
• Grower : fait évoluer un produit lancé pour mieux l'ajuster à son marché ;
• Maintainer : tient un système mature, sa sécurité, sa fiabilité, sa performance à l'échelle.

Trois précisions font la valeur du cadre, toutes dans son post. Les archétypes ne sont pas liés à la fonction d'origine : des designers, des ingénieurs, des PM se retrouvent dans chacun. Beaucoup de gens en couvrent deux, parfois trois. Une équipe saine a besoin d'un mélange qui dépend du stade du produit : Prototypers, Builders et Sweepers avant de trouver son marché, Sweepers, Growers et Maintainers quand le produit s'y est imposé.

Ce que font Anthropic, Instagram, ElevenLabs et Amazon

Les organisations essaient chacune leur formule :

• Anthropic : d'après Gergely Orosz, qui a interrogé Boris Cherny (04/03/2026), tout le monde y porte le même titre, Member of Technical Staff, par choix, et des non-ingénieurs (data, finance, ventes) codent déjà avec Claude Code. Cherny y livre 20 à 30 pull requests par jour en faisant tourner cinq sessions de Claude en parallèle.
• Instagram est passé de grandes équipes de spécialistes à des pods de quatre à six généralistes, avec un rôle de « product staff » qui mêle PM, design, data science et recherche, selon le podcast de Lenny avec Adam Mosseri (09/07/2026).
• ElevenLabs a supprimé ses titres de poste fin 2024, remplacés par des noms d'équipe ; Victoria Weller, qui dirige ses opérations, en décrit elle-même les risques dans une tribune pour Sifted : progression moins lisible, recrutement plus difficile à cibler, interlocuteurs externes qui attendent des signaux de séniorité.
• Amazon : en septembre 2024, Andy Jassy a demandé à chaque grande organisation de relever d'au moins 15 % le ratio de contributeurs individuels par manager avant fin mars 2025, dans une note sur le retour au bureau qui ne parle pas d'agents.
• Clara Shih, ancienne dirigeante de l'IA chez Meta et chez Salesforce, annonce dans un post LinkedIn de mars 2026 un repli des métiers en trois blocs : construire les produits, les vendre, faire tourner l'entreprise.

Un rôle défini par un résultat

Notre lecture : ces expériences définissent un rôle par le résultat qu'on porte plus que par l'expertise qu'on détient. L'expertise s'obtient en partie à la demande auprès des agents ; ce qui reste rare, c'est le jugement : savoir quoi construire, quoi garder, quoi arrêter. Pour le PM, il s'agit de discerner ce qui mérite d'être construit. Pour le designer, le travail glisse vers les systèmes qui mêlent IA et humains : niveaux d'autonomie, gestion des erreurs, façon de dire l'incertitude.

Pour l'ingénieur, le métier glisse vers le pilotage de plusieurs agents, avec le choix des modèles, la gestion du contexte et la conception des évals comme compétences centrales. C'est aussi notre lecture.

Par étapes, recommande Cognizant : un cas d'usage à forte valeur, le modèle opératoire minimal pour le porter, la preuve, puis l'extension. Les freins tiennent, à notre lecture, au code ancien, à la conformité, à la culture et aux équilibres de pouvoir. Uber a publié un format court qui commence par observer le métier.

Notre lecture des freins, dans les grandes organisations :

• Le code ancien : des bases peu modulaires et mal documentées limitent ce que les outils d'IA peuvent faire et rendent risqué un usage intensif d'agents sur des modifications profondes. L'IA aide à documenter, la modernisation reste à faire.
• La conformité : dans la finance, la santé ou les infrastructures critiques, faire intervenir des agents sur du code, des données sensibles ou des clients pose des questions que les équipes risques et conformité freinent légitimement sans cadre clair.
• La culture : modèles de carrière, primes et habitudes de travail sont calés sur le modèle classique.
• Le pouvoir : un modèle qui réduit le besoin de coordinateurs peut être vécu comme une perte de rôle par les managers intermédiaires. Sans soutien fort de la direction, la résistance reste passive et ne dit pas son nom.

Un blocage décrit, sans mesure

Carlos Gonzalez de Villaumbrosia, PDG de Product School, dit voir plus de 80 % des équipes produit « bloquées au niveau un » : des gains individuels, mais rien qui bouge sur le revenu ni sur la vitesse de livraison. Il s'appuie sur plus de 1 400 équipes accompagnées en douze ans et lance, dans le même texte, un cabinet de conseil en IA. C'est une observation, sans méthode publiée.

McKinsey tire de plus de 50 chantiers d'agents six leçons (12/09/2025), dont la première : ce qui compte est le flux de travail, plus que l'agent. Le cabinet note que beaucoup d'entreprises peinent à tirer de la valeur de leurs investissements, et que certaines réembauchent là où les agents ont échoué.

Pour la société de services HTEC, dans un point de vue du 28/05/2026, l'obstacle est le modèle opératoire. L'unité de travail y passe du projet à la « tranche » : bornée, inscrite dans un vrai flux de travail, portée par un responsable de compte de résultat, avec des points de décision explicites. Les décisions se rapprochent de ceux qui font le travail. C'est une thèse de prestataire, sans données.

Commencer petit, sur un cas qui compte

Cognizant recommande dans un article du 12/05/2026 l'approche dite du « fil d'acier » (steel thread) : choisir un cas d'usage à forte valeur et à risque maîtrisé, bâtir le modèle opératoire minimal pour le porter, prouver la valeur, puis étendre en reprenant ce modèle comme gabarit.

Le format d'Uber

Le format le plus détaillé qu'on ait lu vient d'Uber. Dans un post du 07/07/2026, son directeur technique, Praveen Neppalli Naga, raconte 16 « agentic pods » menés en deux mois sur 16 fonctions de l'entreprise. Une trentaine d'ingénieurs parmi les plus à l'aise avec l'IA ont été associés chacun à un expert d'un métier (finance, juridique, opérations, marketing, support, RH, achats). Chaque pod dure deux semaines :

1. jours 1 et 2 : observer l'expert, chaque étape, et documenter ses façons de faire ;
2. jour 3 : choisir quoi automatiser ;
3. jours 4 et 5 : construire un agent avec la personne qui fait le métier ;
4. jours 6 à 9 : le valider avec d'autres personnes qui font le même travail ;
5. jour 10 : le livrer.

Autres résultats annoncés : des rapports de suivi financier passés de deux jours à dix minutes, l'assurance qualité web du marketing de deux semaines à cinquante minutes, 9 000 workflows de support manuels remplacés par de l'automatisation en libre-service. Le même post dit que 99 % des ingénieurs d'Uber utilisent des outils d'IA et que plus de 70 % des pull requests sont attribuées à des agents. En avril, son directeur technique avait reconnu avoir épuisé en quatre mois tout le budget annuel d'IA d'Uber, selon The Information, repris par TechCrunch.

Le format tient en deux semaines et commence par deux jours d'observation du métier : c'est ce qui le rend transposable, à notre avis.

Mesurer le bon résultat

Pour le PDG de Product School, l'adoption de l'IA et la consommation de tokens sont de mauvais indicateurs, faciles à gonfler et sans lien avec la valeur : comptent la vitesse de livraison, la satisfaction client et la croissance du revenu. Notre lecture : un programme qui se juge réussi parce que tout le monde a une licence ne mesure que son activité.

Livrer plus vite ne suffit pas : Marty Cagan observe des équipes qui accélèrent sans que leurs résultats s'améliorent. Le code écrit par l'IA laisse des défauts qui durent, la revue devient un goulot, et les produits d'IA dégagent moins de marge que le logiciel classique. Notre lecture : le jugement humain reste la ressource rare.

Dans The AI Productivity Paradox (23/07/2026), Marty Cagan observe des équipes qui livrent manifestement plus vite grâce à l'IA sans que leurs résultats s'améliorent. Pour lui, le problème du modèle par projets n'a jamais été sa lenteur : il vise ce qu'on livre plutôt que l'effet obtenu, et les idées des dirigeants se révèlent trop souvent ne pas valoir d'être construites.

Il cite une enquête d'Atlassian : 89 % des dirigeants interrogés disent que l'IA accélère le travail, 6 % seulement sont sûrs d'avoir des exemples clairs d'un retour sur investissement à l'échelle de l'organisation (State of Teams 2026, 173 dirigeants de grandes entreprises américaines, janvier et février 2026).

Les deux thèses ne portent pas sur le même objet. Gupta et Varma décrivent ce que font des entreprises nées avec l'IA ; Cagan décrit ce qui arrive quand une entreprise branche l'IA sur un modèle par projets inchangé, et son texte ne cite pas le leur. Dans le même entretien, il rappelle que l'IA est un outil, qui peut aussi accélérer un mauvais processus.

Le code et la revue

Côté code, une étude d'universitaires de Singapour, d'Australie, du Canada et de Chine sur environ 300 000 commits écrits par des assistants d'IA, dans plus de 6 000 dépôts publics, trouve que près de 90 % des problèmes introduits sont des problèmes de maintenabilité (« code smells »), et que 22,7 % de ceux qu'elle suit sont encore là dans la dernière version du dépôt. Elle ne compare pas au code écrit par des humains.

Côté revue, le rapport 2025 de Faros, tiré de la télémétrie de plus de 10 000 développeurs dans 1 255 équipes, compare chaque équipe à elle-même entre ses trimestres de faible et de forte adoption de l'IA : les pull requests fusionnées par développeur augmentent de 98 %, le temps médian de revue de 91 %, les tâches livrées de 21 %.

Faros vend la mesure de l'ingénierie, et ses chiffres bougent d'une édition à l'autre. Son rapport du printemps 2026 ne trouve plus que 16 % de pull requests fusionnées en plus, pour un temps médian passé en revue multiplié par plus de cinq ; dans son édition de septembre 2026, les pull requests fusionnées sans aucune revue augmentent de 76 %.

L'économie et le jugement

Les produits d'IA dégagent moins de marge que le logiciel classique, parce que chaque usage déclenche un coût de calcul. Bessemer estime en février 2026 leur marge brute à 50 à 60 %, contre 80 à 90 % pour le SaaS, sans dire sur quelle base. À notre lecture, le levier sur les effectifs se paie donc en partie en coût variable, ce qui rejoint notre carnet sur le coût d'usage de l'IA.

Superviser l'IA prend aussi du temps. Glean, qui vend une plateforme d'IA pour l'entreprise, appelle « botsitting » ce travail non reconnu (fournir le contexte, contrôler les sorties, corriger les erreurs) et l'estime à 6,4 heures par semaine d'après les 6 000 salariés qu'il a interrogés (Work AI Index, 10/06/2026).

Notre lecture : le jugement humain garde le dernier mot, et c'est ce que ce modèle rend plus rare et plus cher. Savoir quoi construire, repérer une solution juste localement mais fausse pour le produit, décider ce qui sert la stratégie : aucune source ne montre que les agents le font aujourd'hui.

Si les entreprises nées avec l'IA obtiennent de meilleurs résultats en plus de la vitesse ; ce que pèse vraiment la coordination ; ce que deviennent ces modèles dans une grande organisation européenne ; ce que coûte la supervision ; et si les rôles fusionnés tiennent dans la durée.

• Aucune mesure ne relie le nouveau modèle à de meilleurs résultats. Les ratios d'équipe et les gains de vitesse viennent des entreprises elles-mêmes ; nous n'avons trouvé aucune comparaison de leurs résultats produit avec ceux d'équipes organisées autrement.
• La coordination n'est pas mesurée. Les 30 à 50 % de Gupta et Varma sont une estimation ; nous n'avons trouvé aucune étude qui mesure la part de l'effort d'une équipe produit consacrée à se coordonner.
• Les grandes organisations européennes sont absentes. Presque tous les cas sont américains et viennent d'entreprises de la tech ; Uber est le seul grand groupe dont nous ayons lu un format détaillé, sans méthode de mesure ni échecs publiés.
• Le coût de la supervision reste déclaratif. Hors revue de code, que mesure la télémétrie d'un éditeur, le temps passé à contrôler et corriger l'IA n'est connu que par des enquêtes d'éditeurs.
• La durée des rôles fusionnés est inconnue. Les titres supprimés, les archétypes et le rôle de product staff datent de 2024 à 2026 ; on ne sait pas encore comment ces organisations gèrent la progression et les carrières.

Distinguer le récit d'entreprise de la mesure, savoir qui parle et ce qu'il vend, dater chaque chiffre, et se méfier des ratios qui circulent de relais en relais.

• Beaucoup de chiffres sont des récits d'entreprise : les pods d'Uber, la cadence d'Anthropic, l'équipe Codex. Ils ne sont pas audités et ne disent ni leur méthode de mesure ni les échecs.
• Plusieurs sources vendent ce qu'elles décrivent : Rohan Varma travaille sur Codex et enseigne le cours de Product Faculty que nous citons pour l'AI PRD, Product School lance un cabinet de conseil, Faros vend la mesure de l'ingénierie, Glean une plateforme d'IA, GitHub l'outil qu'il a mesuré.
• Les ratios bougent selon la source : Engineering Leadership donne pour Codex un PM et deux designers sur environ 40 personnes, Gupta et Varma deux PM, un designer et une quarantaine d'ingénieurs au lancement. Les mêmes auteurs prêtent à Cursor quarante ingénieurs et un seul PM, sans source, alors que Rohan Varma se présente lui-même comme l'un des deux PM de Cursor à ses débuts, et que les estimations d'effectif de l'entreprise se comptent en centaines.
• Les dates comptent : l'essai de GitHub date de 2022, la note d'Amazon de 2024, la suppression des titres chez ElevenLabs de fin 2024 ; l'étude sur le code écrit par l'IA a été révisée en octobre 2026, et Faros a publié deux nouvelles éditions en 2026.
• Un résumé n'est pas une source : la règle prêtée à Anthropic sur les outils utilisés le lendemain vient d'un résumé publié sur X, et le titre unique de ses salariés d'un journaliste qui a interrogé Boris Cherny, alors que les offres d'emploi publiques de l'entreprise portent des intitulés distincts.