Loop Engineering pour les Product Managers : la compétence de demain n'est pas le prompt

Il existe une idée tenace selon laquelle le Loop Engineering serait une affaire d'ingénieurs — une discipline de développeurs qui versionnent du code et orchestrent des sous-agents. C'est une erreur de perspective. Shubham Saboo, qui travaille sur les produits IA chez un grand fournisseur cloud et a créé la collection « Awesome LLM Apps », l'un des dépôts les plus étoilés de GitHub, défend une thèse simple : la prochaine compétence des Product Managers n'est pas le prompt engineering, mais la conception de boucles. Le mouvement « loop engineering » lui-même est récent — l'article fondateur d'Addy Osmani date de juin 2026 (addyosmani.com) — et son extension au métier de PM l'est plus encore.

L'argument tient en une phrase : le rôle du PM se dédouble. Le métier consistait historiquement en une traduction — parler aux clients, synthétiser leurs problèmes, écrire des spécifications, les passer aux ingénieurs. Le PM était le pont entre « ce dont les gens ont besoin » et « ce qui est construit ». Cette fonction de traduction demeure, mais une couche s'ajoute par-dessus : le PM conçoit désormais les systèmes qui rendent le jugement produit reproductible. Cet article explore cette transposition : pourquoi les boucles concernent les PM, à quoi ressemble une première boucle produit, comment les evals deviennent un travail de PM, et pourquoi un dépôt versionné devient la mémoire du produit.

Le goulot d'étranglement s'est déplacé vers l'amont

La ressource rare n'est plus la capacité d'ingénierie : c'est de savoir ce qui vaut réellement la peine d'être construit. C'est la première observation de Saboo, et elle change la nature du travail de PM. Quand les agents rendent la construction quasi instantanée — vous décrivez un tableau de bord et vous obtenez un prototype, vous fournissez dix transcriptions d'appels et vous obtenez une synthèse structurée en quelques minutes — le cycle de « je sais ce qu'on devrait construire » à « le voici » s'effondre de plusieurs semaines à une fraction de journée.

Le premier changement est évident : le PM ne se contente plus d'écrire une spec, de la passer à l'ingénierie, d'attendre, de relire et de recommencer. Il peut façonner directement la première version. Mais, comme pour les ingénieurs, une fois qu'on travaille ainsi pendant quelques semaines, un autre problème surgit : l'espace de travail IA commence à dériver. Le fichier d'instructions de l'agent s'allonge, la routine de revue de PRD devient plus stricte, le workflow de recherche hérite de consignes d'un projet passé, la checklist de lancement gonfle jusqu'à ce que l'agent en ignore la moitié. Un mois plus tard, l'agent écrit de moins bonnes PRD, donne des résumés de recherche génériques, rate la nuance produit qu'il captait avant. Le modèle n'a pas empiré ; ce sont les artefacts qui ont dérivé. C'est ce problème — et non l'amélioration d'un prompt isolé — que le Loop Engineering résout pour les PM. C'est aussi, à l'échelle du PM, exactement le défi de dérive que pose le Context Engineering en environnement de travail IA.

Les artefacts du PM : là où la boucle commence

Pour un ingénieur, la boucle commence avec le code ; pour un PM, elle commence avec les artefacts qui façonnent le travail produit. Saboo en dresse la liste : une routine de revue de PRD, un résumeur d'appels clients, une grille d'évaluation, une checklist de lancement, un workflow de recherche, un fichier d'instructions persistant, un gabarit de prompt, un cadre de priorisation.

Ces artefacts ont une propriété qui les distingue d'un prompt jetable : ils sont durables, réutilisés, et ils encodent votre jugement. Ils façonnent le comportement d'un agent sur des dizaines d'exécutions, pas une seule. Et parce qu'ils sont réutilisés, ils composent dans les deux directions. Un bon artefact rend votre travail plus tranchant chaque semaine ; un mauvais artefact le ralentit chaque semaine, silencieusement, jusqu'à ce que la sortie sonne faux sans qu'on sache dire pourquoi. C'est la raison précise pour laquelle ces artefacts ont besoin de boucles : un prompt ponctuel, on peut se permettre de le rater ; une grille dont dix personnes dépendent, non.

La distinction entre les trois niveaux — prompt, artefact, boucle — est au cœur de la pratique. Prenons la recherche client. La version simple consiste à demander à un agent : « résume ces appels ». Utile une fois, mais sans amélioration. La version meilleure est un résumeur qui sait ce qui compte pour votre équipe : points de douleur, contournement actuel, urgence, objections, manques produit, citations exactes, suivis. La version boucle tourne chaque semaine : elle utilise le résumeur, compare les nouveaux appels aux thèmes précédents, signale ce qui se répète, ce qui est nouveau, et là où la preuve est mince. Vous relisez la sortie ; si elle a raté une nuance, vous améliorez l'artefact, pas le prompt. Le prompting aide à faire la tâche une fois ; le Loop Engineering améliore l'artefact qui façonne la manière dont la tâche est faite à chaque fois.

Votre première boucle : le signal produit hebdomadaire

La première boucle qu'un PM devrait construire n'est pas une boucle de stratégie — trop large, trop subjective, trop facile à rater — mais une boucle d'opérations produit, là où le travail est répété, les preuves présentes et la cohérence décisive. Concrètement : une boucle de signal produit hebdomadaire.

Voici son fonctionnement. Chaque vendredi, la boucle lit les appels clients, les tickets de support, les notes de vente, les mises à jour d'expérimentations, les résumés analytiques, les changements livrés et les escalades ouvertes. Elle produit un mémo de signal produit unique. Ce mémo ne doit pas être un résumé générique : il doit séparer le signal répété du bruit isolé, inclure le langage exact des clients, montrer ce qui a changé depuis la semaine dernière, signaler là où la preuve est mince, et identifier quelles hypothèses de la feuille de route se sont renforcées, affaiblies ou maintenues.

Puis vient la partie qui fait de cette répétition une boucle : la révision et l'apprentissage. Vous relisez le mémo. S'il a manqué quelque chose d'important, vous mettez à jour l'artefact. Si l'agent a surpondéré une preuve faible, vous resserrez la grille. Si une nouvelle question produit a émergé, vous l'ajoutez à la lentille de la semaine suivante. Après quelques semaines, la boucle devient utile ; après quelques mois, elle devient la chose que vous consultez avant chaque réunion de feuille de route. La leçon de méthode est claire : commencez petit, sur une tâche assez circonscrite pour pouvoir réellement juger si elle s'améliore.

Le goût a toujours compté — mais il lui faut désormais des preuves

Les PM se sont toujours appuyés sur le goût. Un bon PM sent qu'un problème est mal défini en lisant une PRD ; il perçoit qu'une citation client est étirée trop loin ; il voit quand un plan de lancement fait semblant qu'une dépendance n'existe pas. Ce jugement compte toujours. Le Loop Engineering ne le supprime pas — il le place au centre.

Mais une nuance est décisive : quand vous mettez votre jugement dans des artefacts réutilisables, le goût a besoin de preuves. Si vous modifiez un artefact de revue de PRD, comment savez-vous qu'il s'est amélioré ? Si vous resserrez une checklist de lancement, comment savez-vous qu'elle améliore la préparation au lieu d'ajouter du cérémonial ? C'est ici que les evaluations (evals) deviennent un travail de PM.

Une eval de PM n'a pas besoin d'être un benchmark géant : elle commence avec des exemples connus. Prenez trois PRD fortes et trois PRD faibles, faites tourner votre artefact de revue dessus — a-t-il repéré les vrais manques, évité de chipoter, préservé l'intention produit ? Prenez cinq appels clients que vous comprenez déjà, faites tourner votre résumeur — a-t-il capté la vraie douleur, cité correctement, distingué le signal fort du bruit ? Prenez deux lancements passés, un propre et un raté, faites tourner votre boucle de préparation — aurait-elle attrapé ce qui a réellement cassé ? La question n'est pas « l'agent a-t-il eu l'air intelligent ? » mais « cet artefact s'est-il amélioré face à un jugement produit connu ? ». Saboo emprunte ici la formule de Simon Willison, « les evals comme des tests unitaires » : on fixe la barre à l'eval, pas à la démo. Côté ingénierie, c'est la même discipline que celle de l'eval comme garde-fou du contexte agentique — transposée au jugement produit.

Pourquoi un dépôt versionné devient la mémoire du produit

Une fois qu'on évalue des artefacts, il faut un endroit où cet apprentissage puisse vivre. Sinon, le travail disparaît : vous changez un prompt dans un chat, vous collez une nouvelle consigne dans un fichier, vous ajoutez un exemple, vous retirez une contrainte — la sortie change, mais l'historique est perdu. Quelques semaines plus tard, personne ne sait pourquoi l'agent se comporte ainsi.

C'est là qu'un dépôt versionné (de type GitHub) devient utile au PM : non pour qu'il devienne ingénieur, mais parce qu'il a besoin d'un historique de version pour les artefacts qui façonnent de plus en plus son travail. L'artefact y vit, les changements y vivent, les résultats d'évaluation y vivent, le journal de décision et le chemin de retour arrière y vivent. Si un artefact s'améliore, vous voulez le commit ; s'il empire, vous voulez le diff ; si une checklist de lancement a attrapé un vrai bloqueur, vous voulez que cet apprentissage soit sauvegardé pour le prochain lancement. Le dépôt devient la mémoire du produit.

Cette idée s'articule avec une distinction que Saboo tient à clarifier : le contexte n'est pas la mémoire. Le contexte est ce que le modèle voit pour une seule requête — éphémère, borné, perdu au redémarrage. La mémoire est ce qui est stocké sur disque — persistant, consultable, survivant aux redémarrages. Une boucle de PM a besoin des deux, mais c'est la mémoire persistante, hébergée dans un dépôt versionné, qui lui donne sa puissance dans la durée. La même distinction structure le Context Engineering, où l'on parle de mémoire à plusieurs étages. Saboo va jusqu'à suggérer qu'à l'ère des agents, le prototype tient lieu de spec, et que le portfolio versionné d'un PM devient sa preuve de travail.

Onboarder un agent comme on onboarde un employé

Une autre voix éclaire la dimension managériale du Loop Engineering pour les PM : Claire Vo, fondatrice de ChatPRD et animatrice de l'émission « How I AI ». Sa formule : « This is the time for the manager. You are designing a job. […] imagine that you're onboarding an employee » — c'est l'heure du manager ; vous concevez un poste ; imaginez que vous intégrez un nouvel employé.

Cette image change la posture. Concevoir une boucle, ce n'est pas écrire des instructions à une machine ; c'est définir un rôle, des responsabilités, des critères de réussite et des limites — exactement ce qu'on ferait en accueillant une recrue. Vo démystifie d'ailleurs le concept : « If you have used a scheduled task in Claude Cowork […] you have written a loop » — si vous avez déjà programmé une tâche planifiée, vous avez déjà écrit une boucle. L'essence du Loop Engineering, selon elle, tient à un rappel : on n'a pas besoin d'utiliser ses doigts pour taper un prompt afin que son agent travaille.

Dans son émission, Vo distingue quatre types de boucles — heartbeat (battement de cœur), cron (planifiée), hook (déclenchée par un événement) et goal (par objectif) — et en construit deux en direct : un relecteur quotidien de pull requests vieillissantes, et une boucle hebdomadaire d'identification de compétences. À chaque fois, elle s'appuie sur le modèle mental de l'employé qu'on intègre et sur les éléments dont toute boucle a besoin — la même grammaire que dans l'anatomie d'une boucle, appliquée au travail produit plutôt qu'au code.

Cette transposition métier n'est pas isolée. Côté SFEIR, elle prolonge une lecture déjà engagée sur la recomposition des rôles à l'ère des agents : celle du Product Engineer, ce nouveau rôle qui fusionne les spécialités, et celle de la Sandwich Team, la nouvelle forme d'équipe produit. Le PM qui conçoit des boucles ne change pas de métier : il étend son périmètre vers la conception du système qui exécute son jugement.

Le PM gère désormais une flotte d'agents, pas des prompts

À mesure que les boucles se multiplient, le PM ne pilote plus un agent unique mais une flotte d'agents. Saboo en fait une thèse : les PM modernes gèrent des équipes d'agents IA, pas des prompts. Gérer une flotte suppose une organisation de la mémoire à deux niveaux : des notes de travail en ajout permanent (append-only), qui consignent au fil de l'eau ce que les agents font, et une mémoire persistante curée, qui distille les apprentissages durables. Le premier niveau capture tout ; le second retient l'essentiel — la même différence, appliquée à une flotte, qu'entre contexte éphémère et mémoire persistante.

Quand on dirige une personne, on lui parle ; quand on dirige une équipe, on conçoit des rôles, des processus et des critères. De même, prompter convient pour un agent ponctuel, mais dès qu'on coordonne plusieurs agents qui travaillent en continu, il faut concevoir le système qui les organise — c'est-à-dire des boucles. Le PM qui reste au niveau du prompt plafonne à un agent ; celui qui maîtrise le Loop Engineering peut orchestrer une flotte. Ce passage à l'échelle est l'étage produit d'une mécanique que l'ingénierie décrit comme le Harness Engineering : ce qui entoure le modèle compte autant que le modèle.

Ce que le métier de PM devient

Le métier de PM était la traduction : la douleur client en exigences, les objectifs business en feuille de route, les contraintes d'ingénierie en arbitrages. Ce métier demeure. Mais une couche s'ajoute : vous concevez désormais les systèmes qui font que le jugement produit se répète. Vous construisez les artefacts, vous les versionnez, vous les évaluez, et vous remarquez quand ils dérivent. L'agent exécute la tâche ; vous restez responsable de ce que la chose qui l'exécute continue de s'améliorer.

Et chaque boucle de PM sérieuse doit dire ce que l'humain garde en propre. Une boucle peut résumer des preuves clients ; elle ne doit pas décider seule de la stratégie. Une boucle peut réviser une PRD ; elle ne doit pas devenir le leader produit. Une boucle peut signaler un lancement risqué ; elle ne doit pas arbitrer sans contexte. La discipline tient en une formule : construisez la boucle, mais restez le PM. Les meilleurs PM ne seront pas ceux qui auront la plus longue bibliothèque de prompts, mais ceux qui sauront quelles parties du travail produit doivent devenir des boucles durables, quels artefacts doivent les guider, et quelles décisions doivent rester humaines.

C'est aussi le déplacement qu'observe SFEIR au-delà du seul métier de PM : la valeur ne se joue plus dans la production d'un livrable isolé — une spec, un prompt, une démo — mais dans la conception de l'environnement qui rend ce livrable reproductible. C'est le passage du prompt engineering (interaction isolée, ROI linéaire) au context engineering (environnement global, mémoire persistante, ROI composé), dont le Loop Engineering produit est, pour les équipes produit, l'expression la plus concrète.

Points clés

• La prochaine compétence des Product Managers n'est pas le prompt engineering mais le Loop Engineering : concevoir, versionner et évaluer les artefacts (grilles, checklists, résumeurs) qui rendent le jugement produit reproductible (Shubham Saboo).
• Le goulot d'étranglement s'est déplacé vers l'amont : quand les agents rendent la construction quasi instantanée, la ressource rare devient « savoir ce qui vaut la peine d'être construit », pas la capacité d'ingénierie.
• La première boucle à construire est une boucle d'opérations produit (signal produit hebdomadaire), jamais une boucle de stratégie : assez circonscrite pour qu'on puisse juger si elle s'améliore.
• Les evals deviennent un travail de PM : faire tourner un artefact sur des exemples connus (PRD fortes/faibles, lancements passés) pour vérifier qu'il s'améliore — « les evals comme des tests unitaires » (Simon Willison) ; fixer la barre à l'eval, pas à la démo.
• Le contexte n'est pas la mémoire : un dépôt versionné devient la mémoire du produit, où vivent artefacts, résultats d'eval, journal de décision et chemin de retour arrière.
• Règle qui borne le pouvoir d'une boucle produit : elle peut résumer, réviser, signaler, alerter — l'arbitrage stratégique reste humain. Construisez la boucle, mais restez le PM.

Sources

1. Shubham Saboo (Senior AI PM, fournisseur cloud) — Loop Engineering for Product Managers, 2026.
2. Claire Vo (fondatrice de ChatPRD) — How I AI (émission), 2026.
3. Addy Osmani (Google) — Loop Engineering — addyosmani.com, 7 juin 2026.
4. Simon Willison — « evals as unit tests » (formule citée par S. Saboo), 2026.
5. SFEIR — AI for IT : la stratégie du 10x (Product Engineer, Sandwich Team), matière first-party, 2026.