La boîte à outils du Product Builder à l'ère de l'IA agentique

La semaine dernière, j'ai publié un post sur le loop engineering — cette pratique qui consiste à faire tourner des agents IA en boucle sur une file de tâches. Les retours ont été nombreux, et beaucoup tenaient en une phrase : « ça ne marche pas dans mon contexte ». Ils avaient raison. Le loop engineering est un outil formidable pour certaines situations et complètement inadapté pour d'autres. C'est exactement ça, le point que je veux développer ici : il n'existe pas de méthode unique pour bien travailler avec l'IA agentique. Il existe une boîte à outils, et la vraie compétence, c'est de savoir lequel sortir selon le moment.

Je vais être honnête sur un point dès le départ. Aucun de ces outils n'est magique, et la plupart ne sont même pas nouveaux. Certains existaient bien avant l'IA et n'ont jamais été aussi pertinents. Ce qui a changé, ce n'est pas la nature des outils, c'est leur agencement et le poids relatif de chacun. Avec un développeur humain, on tolérait une spécification floue parce qu'il posait des questions. Avec un agent qui exécute à toute vitesse une consigne mal formulée, la moindre imprécision se paie cash, et au centuple. La boîte à outils du Product Builder, c'est donc autant un ensemble de techniques qu'une discipline.

Voici les huit familles, en survol, avant qu'on entre dans chacune.

Famille	Ce qu'elle couvre	Le réflexe à acquérir
1. Cadrage	Le pourquoi, puis le quoi précis	Investir en amont ce qu'on économise en aval
2. Déterminisme	Lint, types, tests unitaires, E2E, journey	Tout ce qui peut être vérifié par une machine doit l'être
3. Vérification	QA manuelle, spot-check, personas, canari	Ne jamais faire confiance sur parole
4. Économie de contexte	Subagents, rtk, LSP, graphe de code	Le contexte est la ressource la plus rare
5. Orchestration	Loop engineering, workflows, harnais	Industrialiser ce qui est répétitif et cadré
6. Design & produit	Du BP aux maquettes, design system en code	Faire dialoguer le produit et le code
7. Posture	Expertise × IA, choix de l'outil, garder la main	L'outil le plus important, c'est vous
8. Socle classique	Git, code review, observabilité, infra déclarative	Les fondamentaux ne disparaissent pas, ils comptent plus

---

Famille 1 — Le cadrage : le pourquoi avant le quoi

C'est l'outil le plus sous-estimé, et de loin. Quand on découvre l'IA agentique, la tentation est de foncer : on décrit vaguement une fonctionnalité, on lance l'agent, on regarde ce qui sort. Ça marche pour un prototype jetable. Ça ne marche pas pour construire un produit qui tient. La raison est simple : un agent comble les vides de votre spécification par des hypothèses, et il le fait avec un aplomb déconcertant. Si vous ne lui dites pas pourquoi vous construisez ce que vous construisez, il choisira un « pourquoi » à votre place, et vous vous retrouverez avec un travail techniquement correct mais à côté du besoin.

Je passe donc, systématiquement, beaucoup plus de temps qu'on ne l'imagine sur deux choses, dans cet ordre. D'abord l'intention : quel problème on résout, pour qui, et comment on saura que c'est réussi. Ensuite seulement le périmètre précis : les parcours utilisateurs, les cas limites, ce qui est dans le scope et — tout aussi important — ce qui n'y est pas. Cette phase ressemble à du temps perdu quand on a un agent qui n'attend qu'un feu vert. C'est en réalité l'investissement au meilleur rendement de tout le cycle. Une heure passée à clarifier le périmètre en économise dix en allers-retours, en réécriture et en débogage de fonctionnalités qui n'auraient jamais dû exister.

Le cadrage ne vit pas que dans votre tête ou dans un document Notion qui pourrit. Il vit dans la mémoire du projet : un monorepo où le code, les décisions, les contraintes et l'historique cohabitent et sont accessibles à la fois à vous et à l'IA. C'est ce que j'appelle le monorepo-mémoire, et c'est devenu le socle de toute ma façon de travailler. Quand l'IA agentique sait écrire et générer presque tout, le code, le deck et la roadmap deviennent des artefacts régénérables ; ce qui reste rare et précieux, c'est la mémoire structurée de l'entreprise — son intention, ses choix, son contexte. Le cadrage, c'est l'acte d'alimenter cette mémoire avant de coder. Sans lui, tous les autres outils tournent à vide.

Famille 2 — Le déterminisme : votre meilleur allié face au probabiliste

Voici le principe qui structure ma façon de travailler : tout ce qui peut être rendu déterministe doit l'être. Un modèle de langage est, par nature, probabiliste — il produit du plausible, pas du garanti. Or on ne construit pas un produit fiable sur du plausible. La parade n'est pas de se méfier de l'IA en permanence, ce serait épuisant et contre-productif ; c'est d'entourer sa production probabiliste d'une cage d'outils déterministes qui, eux, ne mentent jamais.

Ces outils, vous les connaissez déjà, parce qu'ils existaient bien avant l'IA. Le linter et le formateur qui imposent un style et attrapent des erreurs bêtes. Le typage statique — TypeScript en mode strict, PHPStan — qui transforme une classe entière de bugs en erreurs de compilation. Les tests unitaires qui vérifient la logique. Les tests end-to-end, à la Playwright, qui rejouent les parcours réels dans un vrai navigateur. Et au sommet, les tests de journey qui valident des scénarios complets traversant plusieurs fonctionnalités. Rien de neuf. Sauf que leur valeur a explosé.

Pourquoi ? Parce qu'un agent peut produire en une heure ce qu'un développeur produisait en une journée, et qu'il faut donc une cage de vérification capable de suivre ce rythme. C'est précisément ce qui m'a permis de livrer une académie de formation complète — 51 stories, 4 sprints, zéro régression avec des agents autonomes : un harnais de tests à trois niveaux qui attrapait toute dérive avant qu'elle n'atteigne la production. L'agent code vite, mais il ne peut pas mentir à un test E2E qui échoue. Le déterminisme est le contrepoids exact de la vitesse probabiliste. Et si vous voulez mesurer si tout ça fonctionne vraiment, les métriques DORA — fréquence de déploiement, taux d'échec des changements, temps de restauration — restent l'étalon. Elles n'ont pas pris une ride ; elles disent simplement, désormais, si votre cage tient le choc.

Un conseil de terrain pour finir cette famille : à chaque bug trouvé, ajoutez le test qui l'aurait attrapé. C'est une discipline ennuyeuse et c'est ce qui fait que votre cage se resserre avec le temps au lieu de se relâcher.

Famille 3 — La vérification : ne jamais faire confiance sur parole

Le déterministe attrape ce qu'on a pensé à vérifier. Il reste tout le reste — et c'est là qu'intervient la vérification humaine, ou semi-humaine. C'est une famille à part, parce qu'elle repose sur une posture plutôt que sur un outillage : ne jamais croire un livrable sur parole, surtout quand c'est un agent qui vous le présente.

Un agent, quand il a fini une tâche, vous en fait un rapport. Et ses rapports sont presque toujours optimistes. « Tout est vert, tout est vérifié. » Dans la grande majorité des cas, c'est vrai. Mais ce n'est pas votre travail de parier sur la majorité des cas quand le coût d'une erreur en production est élevé. Récemment, en migrant toute mon infrastructure de bases de données vers une nouvelle architecture, j'ai pris l'habitude de re-vérifier moi-même chaque livrable d'agent : un agent m'annonçait une migration réussie, je relançais le décompte des documents, je testais la connexion, je vérifiais que le rollback était intact. Plusieurs fois, le rapport était juste mais incomplet. Une fois, un agent a affirmé avoir écrit un fichier qui n'était en réalité pas sur le disque. Sans ce réflexe de vérification, c'est la production qui prend.

Cette famille comprend plusieurs outils. Les sessions de QA manuelle à l'ancienne : on prend le produit, on l'utilise vraiment, et on note tous les bugs trouvés comme le faisait un testeur QA avant l'IA. Ça paraît rétrograde ; c'est irremplaçable, parce que l'œil humain attrape des incohérences qu'aucun test automatique n'anticipe. Le canari : un smoke test après chaque changement sensible, une simple requête qui confirme que le service répond toujours. La vérification adversariale : faire examiner une affirmation par d'autres agents dont le seul rôle est d'essayer de la réfuter. Et une technique que j'aime particulièrement, le test de maquettes par des personas joués par l'IA : on confronte une interface à des profils utilisateurs simulés avant même d'écrire la moindre ligne de code, et on récolte des retours que l'équipe interne n'aurait jamais formulés. La vérification, ce n'est pas de la défiance ; c'est de la rigueur.

Famille 4 — L'économie de contexte : la ressource la plus rare

Voici une famille que les gens découvrent souvent trop tard, parce qu'elle est invisible jusqu'à ce qu'elle devienne un mur. Quand vous travaillez avec un agent, sa « fenêtre de contexte » — sa mémoire de travail — est limitée. Chaque fichier lu, chaque commande exécutée, chaque rapport encaissé la remplit. Et quand elle déborde, la qualité s'effondre : l'agent oublie le début de sa tâche, perd le fil, recommence des choses déjà faites. Le contexte est, très concrètement, la ressource la plus rare de tout le système. Apprendre à l'économiser, c'est doubler votre capacité de travail sans rien changer d'autre.

Le premier outil, le plus puissant, ce sont les subagents. Au lieu de tout faire dans un seul fil qui se sature, on délègue les tâches lourdes ou parallélisables à des agents secondaires qui démarrent avec un contexte vierge, font leur travail, et ne vous rendent que la conclusion. La recherche dans une grande base de code, l'exécution d'une migration, l'écriture d'un long document : tout ça part chez des subagents, et votre fil principal reste clair. Pendant cette même migration d'infrastructure dont je parlais, j'ai délégué pratiquement chaque gros morceau à un subagent en contexte frais — c'est ce qui m'a permis de tenir une opération de plusieurs heures sans m'effondrer sous le poids du contexte accumulé.

À côté des subagents, il y a un outillage plus discret mais redoutablement efficace, qu'on oublie de mentionner parce qu'il est technique. rtk (Rust Token Killer) est un proxy en ligne de commande qui réécrit de manière transparente les commandes de développement courantes pour réduire de 60 à 90 % le volume de tokens de leurs sorties — un git status ou un build verbeux n'engloutissent plus votre contexte. LSP (Language Server Protocol) donne à l'agent une intelligence de code précise — aller à la définition, trouver les références, connaître les types — sans avoir à lire et relire des fichiers entiers. Et le graphe de connaissance du code (un serveur de type codebase-memory) indexe tout le dépôt et permet de requêter sa structure — qui appelle cette fonction, quelle est l'architecture, où est ce symbole — au lieu d'ingérer des milliers de lignes pour répondre à une question qu'une requête de graphe règle en une fraction du contexte. Pris ensemble, ces trois outils changent l'échelle de ce qu'un seul agent peut traiter avant de saturer. C'est de la plomberie, mais c'est de la plomberie qui décide si vous tenez une heure ou une journée.

Famille 5 — L'orchestration : industrialiser ce qui est cadré et répétitif

On arrive à la famille qui a déclenché cet article. L'orchestration, c'est l'art de faire travailler plusieurs agents ensemble, dans un ordre maîtrisé, pour traiter un volume que vous ne pourriez pas piloter à la main. Le loop engineering en fait partie : une file de tâches, des agents qui la dépilent en boucle, un contrat clair entre eux. Les workflows déterministes en font partie aussi — on décrit en code le fan-out, les étapes, les points de vérification, et on laisse tourner. Les harnais — comme le harnais de tests à trois niveaux ou le harnais complet qui enchaîne implémentation, tests et boucle de convergence — en sont la version la plus aboutie.

Mais c'est précisément ici qu'il faut être honnête, parce que c'est le piège dans lequel beaucoup tombent, moi le premier au début. L'orchestration n'est puissante que sur du travail bien cadré, testable et répétitif. Une académie de formation avec 51 stories similaires et un harnais de tests solide ? Le loop engineering excelle. Une migration d'infrastructure pleine d'inconnues, de décisions irréversibles et de cas particuliers ? L'orchestration automatique serait dangereuse, et là je reprends la main, j'avance pas à pas, je vérifie à chaque étape. Le retour de mes lecteurs LinkedIn — « ça ne marche pas dans mon contexte » — était juste, parce qu'ils décrivaient des contextes exploratoires, ambigus, ou à fort enjeu, où l'on ne lâche pas une boucle d'agents en autonomie.

La règle que j'en tire est simple. Plus le travail est spécifié, testable et répétitif, plus vous pouvez l'orchestrer et l'automatiser. Plus il est flou, exploratoire ou à conséquence forte, plus vous devez le garder en pilotage manuel, rapproché. L'orchestration n'est pas un niveau supérieur de maîtrise qu'on atteindrait une fois pour toutes ; c'est un outil avec un domaine de validité précis. Confondre les deux, c'est s'exposer à des dégâts à la vitesse de la machine.

Famille 6 — Le design et le produit augmentés

On parle beaucoup de l'IA qui code, beaucoup moins de l'IA qui conçoit. C'est dommage, parce que c'est là que se jouent certains des plus grands gains de temps, et qu'un Product Builder se distingue d'un simple développeur assisté. La conception produit et le design ne sont plus une étape déconnectée en amont du code ; ils deviennent un harnais qui pilote le développement.

Concrètement, je suis aujourd'hui capable de partir d'un business plan et d'un cahier des charges pour en sortir, en quelques heures de pilotage, un design system, plusieurs variantes d'interface et des dizaines d'écrans implémentables. Ce n'est pas de la magie : c'est un processus outillé, où chaque étape est cadrée et validée. Une fois ces maquettes posées, elles ne dorment pas dans un fichier Figma à part : elles vivent à côté du code, versionnées, et forment avec le modèle de données un double harnais qui guide les agents pendant le développement. L'agent ne devine pas l'interface ; il l'implémente à partir d'une référence visuelle explicite.

Et la frontière entre design et code continue de s'effacer. Un Product Designer peut désormais mettre à jour le design system directement dans le code, sans repasser par un développeur, en s'appuyant sur l'IA pour faire le pont. Le bénéfice n'est pas qu'une question de vitesse : c'est moins de décalage entre l'intention de design et ce qui finit en production, donc moins de ces frictions où le résultat livré ne ressemble pas tout à fait à la maquette. Cette famille d'outils est celle qui transforme le plus visiblement la composition des équipes — un profil qui maîtrise à la fois le produit, le design et un peu de code devient extraordinairement productif.

Famille 7 — La posture : l'outil le plus important, c'est vous

J'ai gardé la famille la plus importante pour la fin, parce qu'elle commande toutes les autres. Tous les outils précédents ne valent que par la personne qui les manie. C'est un message qui dérange à l'heure où l'on vend l'IA comme un substitut, mais il est au cœur de tout : l'IA n'invente pas l'expertise, elle l'amplifie. J'en ai fait un article entier, parce que c'est le malentendu le plus coûteux du moment. Donnez la même boîte à outils à un expert et à un débutant, et vous obtiendrez deux résultats sans aucun rapport. L'expert sait quel outil sortir, sait reconnaître quand l'IA propose une solution plausible mais fausse, sait quand s'arrêter. Le débutant produit vite quelque chose qui a l'air de marcher et qui s'effondre au premier cas limite.

La posture, c'est d'abord cette compétence méta : savoir quel outil pour quel contexte. C'est tout le propos de cet article. Le loop engineering pour le répétitif cadré, le pilotage manuel pour l'exploratoire à enjeu, le déterminisme partout où c'est possible, la vérification systématique quand le coût d'erreur est élevé. Aucune de ces décisions ne se délègue à l'IA ; elles relèvent du jugement, et le jugement se construit avec l'expérience. C'est aussi pour ça que je garde toujours la main sur la revue du code généré : déléguer l'écriture ne veut pas dire déléguer la responsabilité.

C'est enfin une question de profil. Le builder qui tire le mieux parti de cette boîte à outils n'est ni un pur développeur, ni un pur chef de produit. C'est un profil hybride, que j'ai décrit ailleurs sous le nom de PO Technique : quelqu'un qui comprend assez le produit pour cadrer juste, assez la technique pour savoir ce qui est délégable, et assez l'IA pour orchestrer le reste. Ce profil, aujourd'hui, fait à lui seul le travail d'une petite équipe. Pas parce qu'il code plus vite, mais parce qu'il sait composer ces outils ensemble.

Famille 8 — Le socle classique, qui compte plus que jamais

Je termine par une famille qu'on serait tenté de zapper parce qu'elle n'a rien à voir avec l'IA, et c'est justement pour ça qu'il faut en parler. Les fondamentaux du métier ne disparaissent pas à l'ère agentique ; ils deviennent plus structurants, parce qu'ils sont le filet sous le funambule.

Tout versionner, d'abord. Git n'est plus seulement pour le code : le code, l'infrastructure, les docs, les maquettes, tout passe en Git, parce que c'est ce qui rend chaque chose traçable, revue, et réversible. Quand un agent fait une bêtise, un git revert vous sauve — à condition que tout soit versionné. La revue de code ensuite, humaine, sur ce que produisent les agents. L'observabilité — monitoring, logs, alertes — parce que la seule façon de savoir si ce que vous avez livré fonctionne vraiment en production, c'est de la regarder tourner ; c'est elle qui transforme un « ça devrait marcher » en « ça marche ». Et l'infrastructure déclarative, reproductible, rejouable, dont j'ai détaillé l'anatomie complète sur un cluster bare-metal : quand votre infra est décrite en code, vous pouvez la reconstruire, la migrer, la rejouer — exactement comme le reste.

Ces outils-là ne sont pas excitants. On n'en fait pas des posts viraux. Mais ce sont eux qui font la différence entre une démo qui impressionne et un produit qui tient en production. L'IA agentique vous permet d'aller vite ; le socle classique est ce qui vous permet d'aller vite sans vous écraser au premier virage.

---

Comment ces outils se composent — un exemple réel

Lister huit familles d'outils donne une fausse impression : celle qu'on les utilise séparément, l'un après l'autre. En pratique, c'est leur composition qui fait le travail, et aucun ne suffit seul. Un exemple récent, tiré de ma propre infrastructure, le montre mieux qu'une explication abstraite.

J'avais à migrer toutes mes bases de données — la production de plusieurs produits, des données vivantes — vers une nouvelle architecture mutualisée. Une opération à fort enjeu, irréversible par endroits, pleine de cas particuliers. Regardez comment les familles se sont enchaînées. D'abord le cadrage : avant la moindre commande, j'ai tranché le modèle cible — pourquoi mutualiser, qui consomme quoi, ce qui reste isolé — parce qu'une migration mal pensée se répare très mal. Ensuite l'économie de contexte : chaque gros morceau — construire la plateforme, migrer les données, repointer les applications — est parti chez un subagent en contexte frais, ce qui m'a permis de tenir une opération de plusieurs heures sans saturer. Pendant tout ce temps, le déterminisme travaillait en sourdine : chaque manifeste passait un build de validation avant d'être appliqué, parce qu'une erreur de syntaxe sur une infrastructure, c'est une panne.

Puis la vérification, omniprésente, parce que l'enjeu était élevé. Chaque rapport d'agent, je le re-checkais moi-même : un agent m'annonçait une migration réussie, je recomptais les documents des deux côtés — 705 documents, comptages identiques — avant de le croire. Un canari tournait en boucle : une requête sur mon site public, qui devait rester à 200 à chaque étape, et qui m'aurait alerté à la seconde où quelque chose cassait. Et c'est là qu'intervient le choix le plus important : je n'ai pas orchestré cette migration en loop engineering. Sur du travail à conséquence forte et à inconnues multiples, j'ai gardé le pilotage manuel, rapproché, étape par étape — exactement l'inverse de ce que j'aurais fait sur 51 stories répétitives. Enfin, le socle était mon filet : tout en Git, chaque changement réversible par un simple revert, l'ancienne base gardée chaude le temps de confirmer la stabilité.

Aucun de ces outils n'aurait suffi. Le cadrage sans vérification aurait laissé passer des erreurs d'exécution. Les subagents sans déterminisme auraient produit du plausible non testé. L'orchestration automatique aurait été un désastre sur ce terrain-là. C'est l'agencement — le bon outil à la bonne étape, et l'outil rangé quand il ne convenait pas — qui a fait qu'une migration risquée s'est déroulée sans une seconde d'interruption visible. Voilà ce que veut dire « manier la boîte à outils ». Pas connaître les outils. Savoir les composer.

---

La vraie compétence : savoir choisir

Si vous deviez ne retenir qu'une chose, ce serait celle-ci. Il n'y a pas de méthode unique pour bien travailler avec l'IA agentique, et celui qui vous en vend une se trompe ou vous trompe. Il y a une boîte à outils — cadrage, déterminisme, vérification, économie de contexte, orchestration, design, posture, socle — et une compétence qui les surplombe toutes : savoir lequel sortir, quand, et surtout quand le ranger. Le loop engineering est un excellent outil. Il n'est pas universel. Aucun ne l'est.

Cette compétence du choix ne se transmet pas en lisant un article, aussi long soit-il. Elle se construit par la pratique, en se trompant, en mesurant, en affinant. C'est exactement ce que je m'attache à transmettre quand j'accompagne des équipes : non pas « voici LA méthode », mais « voici la caisse à outils, voici comment chacun fonctionne, et voici comment développer le jugement pour choisir ». Parce qu'au bout du compte, l'outil le plus important de la boîte, ce n'est aucun de ceux que j'ai listés. C'est vous.