AI Product Operating Model : l'inversion du modèle Cagan

Le product operating model popularisé par Marty Cagan repose sur une croyance centrale : dans une entreprise technologique, la ressource la plus rare et la plus coûteuse est l'ingénieur, et écrire du code est l'activité au coût marginal le plus élevé. Ce n'est pas un détail théorique, c'est le socle qui irrigue toute la conception de l'organisation produit : la façon de staffer les équipes, de prioriser, les rituels mis en place, le rôle assigné à chacun dans le trio product manager, designer, ingénieur. La mission d'une équipe produit n'y est pas de maximiser le nombre de fonctionnalités livrées, mais de tirer le maximum de valeur d'une capacité de développement limitée et chère. Le livre TRANSFORMED en donne la version systématisée pour les grandes organisations.

Dans ce paradigme, écrire du code revient à couler du béton : une fois fait, revenir en arrière coûte cher. La comparaison n'est pas que métaphorique. Beaucoup d'organisations dites produit travaillent sur des roadmaps trimestrielles difficiles à ajuster une fois engagées, avec des processus de changement de scope lourds et des arbitrages qui remontent haut, précisément parce que chaque pivot consomme des semaines d'ingénierie supposées rares. Toute la chaîne d'outils traditionnelle a été pensée pour ce monde : des backlogs longs, des roadmaps planifiées, des spécifications détaillées, des dashboards d'OKR. Rien, dans cette architecture, n'anticipe un monde où l'on construirait cinq variantes d'une fonctionnalité en quelques heures pour en jeter quatre sans douleur.

Ce modèle a été extraordinairement utile : il a sorti des organisations entières du mode projet, où l'IT exécutait des demandes métier, pour les amener vers des équipes produit durables, responsables de problèmes plutôt que de cahiers des charges. Mais le même socle cognitif limite aujourd'hui la capacité à imaginer un régime où le coût marginal du build approche de zéro. Cagan lui-même, dans A Vision For Product Teams, reconnaît que l'IA générative va modifier la composition des équipes produit, notamment en réduisant le nombre de testeurs, sans proposer pour autant un modèle d'organisation pleinement IA-natif.

Le premier signal chiffré de la bascule est ancien et solide. L'étude de GitHub sur l'impact de Copilot portait sur 95 développeurs en expérience contrôlée : ceux qui utilisaient l'outil ont implémenté un serveur HTTP en JavaScript 55 % plus vite que le groupe témoin (1 h 11 en moyenne contre 2 h 41), avec un taux de réussite supérieur (78 % contre 70 %). Pour un responsable produit, la lecture est claire : la prémisse selon laquelle le code est cher perd de sa validité sur un spectre de tâches de plus en plus large, et la rareté se déplace de l'ingénierie brute vers la capacité à définir les bons problèmes, à orchestrer les agents et à concevoir des systèmes d'évaluation robustes.

Le point de départ est un fait technologique. La combinaison de modèles de langage puissants, d'IDE augmentés, de copilotes intégrés et de frameworks d'agents transforme l'économie du développement. Gupta et Varma rapportent que, dans les organisations IA-natives qu'ils observent, une tâche qui prenait dix heures s'exécute désormais en dix minutes. Ils citent un cas précis : un projet de modernisation estimé à dix ingénieurs sur douze mois, mené à bien par deux ingénieurs en trois jours. On garde une réserve sur ce genre de chiffre, dont la provenance est un témoignage rapporté et non un audit. L'ordre de grandeur, lui, traduit une chute vertigineuse du coût marginal du build pour une classe de tâches bien identifiées : migrations, réécriture de services, génération de tests, documentation, plomberie applicative.

De ce constat vient l'inversion de séquence. La logique du modèle classique repose sur l'idée que construire d'abord et réfléchir ensuite est un luxe inabordable, puisque chaque cycle de build consomme des semaines de travail rare. C'est ce qui justifie les couches de discovery, de PRD et de business case préalables. Quand construire devient assez peu cher pour qu'on puisse construire d'abord et évaluer ensuite, cette logique s'effondre. La question ne sera plus de savoir si l'on devrait construire ceci à partir d'une spécification, mais de décider si l'on shippe le prototype qu'on vient de faire produire par des agents. Dans Intentionally Human, Jeremy Daly souligne que ce prototypage, autrefois affaire de plusieurs jours d'ingénierie, devient presque trivial pour un PM ou un designer un peu à l'aise avec Bolt, V0 ou Lovable.

Cette inversion recompose des pans entiers du cycle. La revue de code comme étape séparée perd de sa pertinence lorsque les agents vérifient déjà leur propre travail à la génération : les humains se concentrent sur la revue de l'output (comportement, performance, sécurité) plutôt que sur les diffs ligne à ligne. Le sprint planning élaboré devient moins utile quand une mauvaise orientation coûte une trentaine de minutes d'agent plutôt que deux semaines d'équipe. Cat Wu, Head of Product de Claude Code chez Anthropic, décrit dans un échange public une cadence de shipping passée de mois à semaines puis à jours, où le travail du PM consiste moins à aligner des roadmaps multi-trimestres qu'à fixer des objectifs clairs et à organiser des boucles d'expérimentation rapides. Quant au PRD, la pédagogie de Product Faculty sur l'AI Product Management le réoriente vers les risques, les garde-fous, les niveaux d'autonomie et les métriques de succès, écrits en parallèle du prototypage plutôt qu'en phase bloquante préalable.

Notre lecture : le mot effondrement est trop fort pour les organisations établies. Ce qu'on y observe, c'est moins la suppression de ces phases que leur intégration dans des boucles plus courtes et mieux outillées. EPAM, dans The future of SDLC is AI-native, décrit un cycle continu où les artefacts d'architecture, les revues de pull request, les tests et la documentation sont auto-générés et auto-actualisés, sans disparaître. L'enjeu n'est pas de jeter code review, sprints et PRD, mais de les reconfigurer autour de cycles centrés sur la qualité des comportements.

Le gisement le plus important est aussi le moins visible. Gupta et Varma estiment qu'entre 30 et 50 % de l'effort d'une équipe traditionnelle correspond à de la coordination : synchroniser PM, designers, ingénieurs, managers et parties prenantes, aligner des roadmaps inter-équipes, discuter des dépendances, planifier les sprints. Dans un monde où implémenter coûte cher, cette coordination est rationnelle : mieux vaut passer trois jours à s'aligner que trois semaines à construire la mauvaise chose. Dans un monde où l'essentiel des expérimentations peut être mené rapidement par de petits groupes, elle devient un frein. C'est précisément là que les entreprises IA-natives prennent leur avance, pas tant en tapant du code plus vite qu'en supprimant les couches de synchronisation que le modèle classique imposait.

Anthropic en est l'archétype. Une vidéo sur le side quest maxxing résume un principe maison : n'importe quel membre de l'équipe peut prototyper une idée, la shipper en interne sans approbation préalable, l'observer en usage réel, et n'investir davantage que si elle continue d'être utilisée au-delà de quarante-huit heures. Les designers y codent, les PM prototypent, les ingénieurs prennent des décisions produit, si bien que la frontière entre discovery et delivery se dissout dans un flux continu de micro-expériences. OpenAI Codex offre un second point de repère, plus mesurable : dix à douze surfaces produit pilotées par un seul product manager, deux designers et une quarantaine d'ingénieurs, là où une entreprise classique aurait staffé chaque surface avec un squad de quinze à vingt personnes.

Au-delà du ratio, c'est l'internalisation de l'IA qui frappe. D'après How OpenAI's Codex team works, l'équipe utilise Codex pour la planification, l'onboarding, la revue de code, les tests et la priorisation ; les nouveaux arrivants sont guidés par l'outil, qui installe leur environnement et leur explique la base de code, ce qui réduit fortement le coût de montée en charge. La même source rappelle que la prochaine vague d'échecs en IA viendra moins de modèles faibles que d'un mauvais context engineering, c'est-à-dire de la façon dont on sélectionne, structure et injecte le contexte dans les agents. Cursor pousse la logique à la caricature : environ quarante ingénieurs, un seul PM, et 2 milliards de dollars d'ARR franchis après un doublement en trois mois.

Les cas extrêmes méritent d'être lus comme des bornes, pas comme des modèles à copier. D'après le playbook Medvi, Matthew Gallagher a généré 410 millions de dollars de revenus et 63 millions de profits en 2025 avec 20 000 dollars de budget marketing, sur une startup de télésanté qui externalise ses couches cliniques et réglementaires. Sa vraie barrière à l'entrée n'est pas l'IA mais une machine de distribution agressive, un programme d'affiliation très généreux qui a produit une prolifération de centaines de faux profils de docteurs sur Facebook. OpenClaw en est la variante plus produit : Peter Steinberger a construit seul cet assistant personnel IA avant de rejoindre OpenAI. Ce que ces cas démontrent n'est pas qu'une entreprise à une personne est le futur, mais que la frontière de ce qu'un très petit groupe peut accomplir s'est nettement déplacée.

Le changement de workflow le plus tangible est le remplacement progressif des sprints par des boucles d'évaluation continue. Vercel décrit, dans Eval-driven development, un processus où l'équipe conçoit d'abord les évals qui définissent ce que bien faire le travail signifie pour un agent, puis s'en sert pour guider l'itération. Pour les systèmes probabilistes, les évals jouent le rôle que les tests end-to-end jouent pour le logiciel déterministe : elles mesurent la qualité des outputs contre des critères définis, en combinant des checks par code pour l'objectif, des jugements humains pour le subjectif, et des évaluations par d'autres modèles pour l'échelle. Red Hat propose un cadre en huit étapes pour évaluer des agents, qui insiste sur l'intégration des évals dans la CI/CD, le test multi-tours et la surveillance des dérives.

Concrètement, l'équipe ne planifie plus des stories sur deux semaines, elle se fixe des objectifs de score : faire passer un agent de 78 % à 90 % de réussite sur un benchmark interne. Les démos montrent l'évolution des scores et des métriques d'usage plutôt qu'une liste de features. C'est un changement de nature de la conversation entre produit et engineering, et c'est aussi ce qui rend le sujet difficile à porter en interne : un tableau de scores parle beaucoup moins à un comité de direction qu'une roadmap de fonctionnalités. La conclusion pratique, c'est qu'un passage à l'eval-driven se prépare autant côté gouvernance et reporting que côté outillage.

À cette logique s'ajoute l'exploration parallèle par side quests. Plutôt que de concentrer toute l'équipe sur un backlog serré, l'organisation encourage des expérimentations menées en parallèle par différents membres, qui prototypent, déploient en interne, collectent des retours et décident de poursuivre ou d'abandonner. Ce modèle n'est pas qu'une affaire de culture : il suppose une infrastructure de déploiement, des pipelines d'évaluation et un monitoring suffisamment industrialisés pour que lancer une expérience soit quasi sans friction. C'est le point que les organisations sous-estiment le plus souvent quand elles essaient d'imiter le fonctionnement d'Anthropic.

Enfin, la spécification elle-même change de nature. Le PRD statique cède la place à un harnais dynamique, un ensemble vivant de tests, d'évals et de contraintes codées. Jeremy Daly explique que l'IA peut générer des suites de tests qui font office de PRD vivants, représentation mesurable et vérifiable des exigences. Product Faculty parle d'AI PRD centrés sur les niveaux d'autonomie accordés à l'IA, les scénarios exigeant un humain dans la boucle, les risques spécifiques de biais, d'hallucination et de sécurité, et les critères de succès qui serviront de base aux évals. Le consultant Benden Blanken plaide pour un AI Agent Operating Model complet, avec propriétaire identifié, garde-fous, versioning des prompts, humain dans la boucle et gouvernance des données. Sa formule mérite d'être retenue : si tout le monde possède l'agent, personne ne le possède.

C'est le versant le plus concret pour un CPO ou un DRH, et celui qui a le plus bougé au premier semestre 2026. Trois mutations convergent. Les équipes rétrécissent : ce qui demandait un pod complet est réalisé par deux ou trois personnes à l'aise avec le code, travaillant avec des agents. Les rôles s'élargissent : la profondeur d'un rôle se payait en largeur, et ce compromis saute quand n'importe qui peut construire en décrivant ce qu'il veut. La hiérarchie s'aplatit, parce qu'une grande partie du milieu de l'organigramme existe pour faire circuler l'information et vérifier la qualité, deux choses que les agents font désormais. L'ancrage théorique reste la two-pizza team de Bezos, dont l'IA déplace la limite en réduisant le coût de coordination par personne.

Le cadre le plus utile vient de Boris Cherny, créateur de Claude Code, qui observe qu'engineering, product, design et data science fondent en un nouveau type de rôle et décrit cinq archétypes qui ne sont pas des titres mais des façons de contribuer selon le stade de vie du produit. Le Prototyper génère des idées en rafale, dont la plupart ne shippent jamais. Le Builder transforme vite un prototype en produit de qualité production. Le Sweeper nettoie l'UI, simplifie le code et dé-shippe, ce qui compte quand environ 80 % des prototypes ne sortent jamais. Le Grower itère sur un produit lancé pour améliorer son product-market fit. Le Maintainer possède un système mature, sa sécurité, sa fiabilité, sa performance à l'échelle. Trois précisions font la valeur du cadre, bien restituées par l'analyse d'Aakash Gupta : les archétypes ne sont pas liés à la fonction d'origine, une même personne en couvre deux ou trois et en change au fil de la semaine, et une équipe saine a besoin d'un mix dont le dosage dépend de la maturité du produit.

Le contexte opérationnel derrière compte autant que le cadre. Chez Anthropic, tout le monde porte le même titre, Member of Technical Staff : le PM code, le designer code, la finance code. Cherny fait tourner cinq instances de Claude Code en parallèle et shippe vingt à trente pull requests par jour, et sa phrase la plus citée résume le déplacement du métier : il ne prompte plus, il écrit des boucles qui promptent. Les organisations établies expérimentent de leur côté. Instagram teste un rôle Product Staff, opérateur généraliste qui fusionne PM, design, data science et research, dans des pods de quatre à six ingénieurs généralistes ; Adam Mosseri décrit dans le podcast de Lenny des fonctions qui commencent à se fondre les unes dans les autres. ElevenLabs a supprimé les titres de poste, remplacés par des noms d'équipe, avec une mise en œuvre soignée et des risques assumés sur la lisibilité externe et la clarté de progression. Amazon a relevé son ratio contributeurs individuels sur managers d'au moins 15 %, et Clara Shih prédit dans un post très repris le repli des catégories d'emploi en trois blocs : construire le produit, le vendre, faire tourner l'entreprise.

Le REX le plus transposable est celui d'Uber. Une trentaine des ingénieurs les plus à l'aise avec l'IA, chacun apparié à un expert métier des RH, de la finance, du juridique, du marketing ou du support, en sprints de deux semaines : 16 agentic pods sur 16 fonctions business en 2 mois. Le déroulé est simple et duplicable : deux jours de shadowing où l'ingénieur observe l'expert travailler et documente les workflows, un jour de priorisation, deux jours pour construire un agent fonctionnel aux côtés de la personne qui fait le métier, quatre jours de validation avec d'autres personnes exerçant le même métier pour vérifier que l'agent généralise, puis ship au dixième jour. Les résultats annoncés, repris par Tekedia, sont spectaculaires : allocation de capital sur 150 villes ramenée de 15 heures à 30 minutes, rapports de pacing financier de 2 jours à 10 minutes, support passé de 9 000 workflows manuels à de l'automatisation self-service. Le CTO Praveen Neppalli annonce par ailleurs que 99 % des ingénieurs utilisent des outils IA et que plus de 70 % des pull requests sont attribuées à des agents.

Notre lecture : le fil rouge de toutes ces expérimentations est qu'on ne définit plus un rôle par une expertise détenue mais par un outcome possédé. L'expertise s'obtient à la demande via les agents ; ce qui reste rare, c'est le jugement, savoir quoi construire, quoi garder, quoi tuer. Pour le PM, la question n'est plus de savoir si l'on peut le construire mais de discerner ce qui mérite de l'être. Pour le designer, le travail se déplace du pixel-perfect vers la conception de systèmes mêlant IA et humain : niveaux d'autonomie, gestion des erreurs, communication de l'incertitude, calibration de la confiance. Pour l'ingénieur, l'étude arXiv sur le code généré par IA rappelle qu'il reste le gardien indispensable de la qualité structurelle, et son métier glisse vers l'orchestration de plusieurs agents aux rôles distincts, avec la sélection des modèles, le context engineering et la conception d'évals comme compétences centrales.

La migration vers un AI Product Operating Model dans une grande organisation se heurte à quatre obstacles bien identifiés. Le premier est la legacy : des bases de code anciennes, peu modulaires et mal documentées limitent l'efficacité des outils IA et rendent risqué un usage intensif d'agents pour des modifications profondes. L'IA peut aider à documenter et à réduire les temps d'onboarding, mais elle ne remplace pas une vraie modernisation, et le risque est de l'utiliser comme un sparadrap qui permet de bricoler plus vite sur une base fragile. Le deuxième est 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 soulève des problèmes que les équipes risk et compliance peuvent légitimement freiner en l'absence de cadres clairs. Le troisième est culturel : modèles de carrière, systèmes d'incentives et habitudes sont calés sur le modèle classique. Le quatrième est plus discret et mérite d'être nommé : la structure de pouvoir. Le modèle IA-natif réduit le besoin d'intermédiaires dédiés à la coordination, ce qui peut être vécu comme une perte de rôle par les managers intermédiaires, et sans sponsorship fort de la direction, les initiatives se heurtent à une résistance passive qui ne dit jamais son nom.

L'ampleur du blocage est documentée. Plus de 80 % des équipes produit resteraient au niveau où les gains individuels de productivité ne se traduisent pas en résultats business. McKinsey, dans One year of agentic AI, parle de pilot purgatory : beaucoup d'entreprises restent bloquées au stade du pilote sympathique, faute d'un modèle opératoire adapté pour passer à l'échelle. L'adoption échoue rarement à cause de la technologie, mais parce que l'organisation n'est pas conçue pour l'absorber. Deux déplacements structurels accompagnent les transitions réussies : l'unité de travail passe du projet, à périmètre, calendrier et budget fixes, à la tranche, mieux adaptée au travail des agents ; et les droits de décision se rapprochent de l'exécution.

Sur la méthode, les sources convergent vers une transition par gradients plutôt que par rupture. EPAM recommande de commencer petit mais significatif, en réunissant un noyau de champions IA pour expérimenter et documenter, de former les ingénieurs aux workflows d'agents, de mettre en place une gouvernance avec review boards et chartes d'agents, et de choisir des pilotes sur des équipes déjà saines en delivery, avec des métriques claires. Cognizant et BCG parlent de steel thread ou de lighthouse use case : choisir un cas d'usage à forte valeur, bâtir un mini modèle opératoire autour, prouver la valeur, puis étendre. Le pod Uber est la meilleure version opérationnelle de ce principe qu'on ait lue cette année, parce qu'il tient en dix jours et qu'il commence par de l'observation.

Un mot sur les indicateurs, parce que c'est là que la plupart des programmes déraillent. Product School martèle dans The AI Operating Model for Product Teams que l'adoption de l'IA et la consommation de tokens sont de mauvais indicateurs : seuls comptent la vélocité de shipping, l'adoption des fonctionnalités et l'impact sur le revenu, le NPS ou la rétention. Beaucoup d'entreprises se déclarent en réussite parce que tout le monde utilise Copilot, sans aucun gain business mesurable. C'est la définition même de l'illusion de progrès, et c'est ce qui rend le contre-argument de la section suivante si difficile à écarter.

Le contre-feu le plus sérieux est venu de Cagan lui-même. Dans The AI Productivity Paradox, il observe des équipes qui livrent manifestement plus vite grâce à l'IA et dont les outcomes ne s'améliorent pas. Son explication est cohérente avec sa grille de toujours : le problème n'a jamais été la vitesse de livraison, mais le fait que la plupart des idées ne sont pas de bonnes solutions aux problèmes qu'elles prétendent résoudre. Accélérer un pipeline qui produit majoritairement des idées médiocres ne fait que produire des idées médiocres plus vite. Les chiffres externes vont dans le même sens : l'enquête State of Teams 2026 d'Atlassian rapporte que 89 % des dirigeants constatent une accélération du travail mais que 6 % seulement se disent capables de pointer un retour sur investissement IA à l'échelle de l'organisation. On ne tranche pas ce débat ici, parce que les deux thèses ne portent pas sur le même objet : Gupta décrit ce que font les entreprises IA-natives, Cagan décrit ce qui arrive quand une entreprise classique branche l'IA sur son modèle opératoire inchangé.

Vient ensuite la qualité du code. L'étude arXiv à grande échelle sur le code généré par IA conclut que le code produit s'accompagne souvent d'une hausse de la dette technique : duplication, complexité cyclomatique, patterns non optimisés, tests inadaptés, d'autant que les développeurs sous pression acceptent les suggestions sans assez de recul. Ce constat rejoint une critique crue, relayée sur les réseaux, selon laquelle l'IA permet surtout de shipper plus de déchet, plus vite. Le risque principal n'est pas l'IA en soi mais l'absence de garde-fous adaptés : la revue ligne à ligne ne suffit plus pour des systèmes dont une grande partie du comportement dépend de prompts, de contexte dynamique et de modèles externes. Il faut des revues de comportement, des évals de robustesse, des tests de résilience.

L'économie du modèle mérite aussi une lecture froide. Les produits IA-natifs affichent des marges brutes de 50 à 65 %, sensiblement inférieures aux 78 à 85 % du SaaS traditionnel, à cause des coûts d'inférence intégrés à chaque interaction. Le levier sur les effectifs se paie donc partiellement en coût variable, et le sujet rejoint directement celui du coût d'usage de l'IA. Par ailleurs, le véritable avantage concurrentiel ne réside pas dans le modèle d'IA lui-même, largement banalisé, mais dans l'expertise métier, les données propriétaires, la confiance et les couches de vérification. Le moat se déplace vers ce que l'IA ne fournit pas.

Restent deux signaux d'honnêteté intellectuelle qu'on tient à garder au dossier. Le premier : les témoignages first-person détaillés et vérifiables restent rares en ligne. Beaucoup de discours, beaucoup de reprises de reprises, peu de retours bruts et chiffrés par ceux qui ont vécu la transition, et une partie des ratios spectaculaires cités plus haut circulent sous forme de récits rapportés plutôt que de mesures auditées. Le second : le botsitting, ce temps passé à superviser l'IA sans valeur tangible, rappelle que superviser peut consommer le temps qu'on croyait libérer. Les agents restent moins bons pour saisir des implications subtiles, repérer une solution localement correcte mais globalement fausse, ou juger si une fonctionnalité sert vraiment la stratégie. La conclusion pratique : le jugement humain garde le dernier mot, et c'est précisément ce que le nouveau modèle rend plus rare et plus cher.