Ton agent n’a pas besoin de plus de contexte. Il a besoin d’un propriétaire.

Il y a une phrase que j’ai de plus en plus envie de coller sur tous les projets IA :

Le problème n’est pas que l’agent ne sait pas faire. Le problème, c’est qu’il ne sait pas quoi croire, quoi ignorer, quoi payer, ni jusqu’où il a le droit d’aller.

Pendant longtemps, on a résumé la productivité IA à une question assez simple : quel modèle utiliser ?

Puis la question est devenue : quel agent utiliser ?

Mais dès que tu essaies de mettre ces agents dans un vrai workflow, avec des clients, des fichiers, des coûts, des permissions, des exceptions métier et des responsabilités, une autre question apparaît.

Qui possède le contexte ?

Pas “qui a mis trois documents dans un prompt”.

Je parle du contexte au sens opératoire : les règles métier, les arbitrages, les données validées, les garde-fous, les droits d’accès, les coûts acceptables, les cas où il faut escalader, les traces qui permettent de comprendre ce que l’agent a fait.

Cette semaine, plusieurs signaux racontent exactement la même chose : la valeur IA se déplace du modèle vers la couche qui contrôle l’exécution.

Au programme :

• Pourquoi le vrai actif devient le contexte métier que tu donnes aux agents

• Pourquoi les agents verticaux ne passeront pas en production sans gouvernance

• Pourquoi la facture IA devient une décision produit, pas une ligne technique

Le vrai coût d’un modèle fermé, c’est le savoir métier que tu lui verses

Le signal le plus intéressant de la semaine vient d’une alerte assez simple : quand une entreprise utilise l’IA, elle ne paie pas seulement avec des tokens.

Elle paie aussi avec son savoir métier.

Ses corrections.

Ses exceptions.

Ses habitudes internes.

Ses décisions passées.

Ses documents propres.

Ses manières de répondre aux clients.

Ses critères implicites.

C’est Satya Nadella, patron de Microsoft, qui averti sur ce sujet : le risque, pour les entreprises, n’est pas seulement de dépendre d’un fournisseur IA. C’est de nourrir ce fournisseur avec assez de contexte interne pour que la couche modèle devienne plus précieuse que la couche métier elle-même.

Dit autrement : si ton agent devient utile uniquement parce que tu lui as donné toute ta connaissance interne, alors la question stratégique n’est pas “quel modèle est le plus puissant ?”

La question devient :

👉 Est-ce que ce contexte t’appartient encore ?

C’est pour ça que je pense qu’on va entendre de plus en plus parler de context engineering.

Atlan résume bien le sujet : le context engineering consiste à organiser les instructions, la mémoire, les outils, les sources et les contraintes qui permettent à un agent de travailler correctement. Pas juste à écrire un meilleur prompt. — Atlan

Pour un Product Builder, c’est une bascule importante.

Hier, tu pouvais créer de la valeur en sachant choisir l’outil, écrire le prompt, connecter deux APIs et produire une V1 plus vite que les autres.

Demain, tu créeras de la valeur en sachant structurer le terrain de travail de l’agent :

• quelles sources sont fiables ;

• quelles règles sont actives ;

• quelles décisions sont obsolètes ;

• quelles données peuvent sortir du système ;

• quels exemples représentent vraiment le métier ;

• quelles exceptions doivent être documentées ;

• quelles traces doivent être conservées.

Le contexte devient une infrastructure.

Et comme toute infrastructure, il faut quelqu’un pour la concevoir, la maintenir et l’améliorer.

C’est là que beaucoup d’entreprises vont se tromper.

Elles vont empiler des copilotes, des abonnements et des agents. Puis elles vont découvrir que le vrai blocage n’est pas l’accès au modèle, mais la qualité de ce qu’elles lui donnent.

Un agent branché sur un contexte sale ne devient pas intelligent.

Il devient simplement plus rapide à produire du flou.

Ce que ça change pour toi :

Si tu construis avec l’IA, commence à regarder ton travail comme un système de contexte.

Pas seulement :

“Quel outil j’utilise ?”

Mais :

“Qu’est-ce que je rends lisible, portable, vérifiable et réutilisable par un agent ?”

C’est une compétence de builder.

Et je pense qu’elle va valoir beaucoup plus cher que la capacité à tester le dernier modèle le jour de sa sortie.

— Pour aller plus loin 🎁

C’est aussi pour ça que j’ai produit un guide autour d’OKF, l’Open Knowledge Format.

L’idée n’est pas de te vendre un format magique.

L’idée est de t’aider à faire un premier tri très concret : quelles connaissances méritent d’être structurées, quelles sources ton agent doit croire, quelles règles doivent être explicites, et comment transformer un dossier flou en contexte réutilisable.

👉 Tu peux le récupérer ici : recevoir le guide OKF.

Et si tu veux mettre ça en place dans ton entreprise, ton équipe ou ton projet, réponds simplement à cet email.

Je peux t’aider à auditer ton contexte actuel, identifier ce qui manque à tes agents, structurer un premier bundle exploitable, et transformer tes documents, règles ou process en base de travail vraiment utilisable par l’IA.

Les agents passent de la démo au produit quand ils deviennent gouvernables

Le deuxième signal vient de la sécurité.

Et je sais, dit comme ça, c’est rarement la partie la plus sexy.

Mais c’est souvent là que les vrais marchés commencent.

L’OWASP a publié son Top 10 for Agentic Applications 2026. Le point important n’est pas seulement la liste des risques. Le point important, c’est qu’on commence à avoir une grammaire commune pour parler des agents en production.

Prompt injection.

Permissions excessives.

Actions non souhaitées.

Dérive de mémoire.

Mauvaise gestion des outils.

Escalade mal cadrée.

Ces problèmes ne sont pas des détails techniques.

Ce sont les raisons pour lesquelles une entreprise peut trouver une démo brillante, puis refuser de la déployer.

Parce qu’un agent qui écrit une réponse moyenne, c’est gênant.

Un agent qui agit avec de mauvais droits, sur de mauvaises données, au mauvais moment, c’est autre chose.

C’est exactement ce que montre aussi l’exemple d’un agent d’assurance pour la gestion de sinistres : le produit ne devient crédible qu’avec des gates humaines, des permissions serrées, des traces d’audit et une architecture capable d’expliquer quand l’agent doit s’arrêter. — dev.to

Et c’est là qu’il y a une opportunité business très claire.

Les meilleurs marchés IA ne sont pas forcément ceux où l’agent peut tout faire tout seul.

Ce sont souvent ceux où l’agent peut faire une partie pénible, fréquente et coûteuse, à condition que le risque soit absorbé par le système autour.

Assurance.

Conformité.

Back-office finance.

Santé documentaire.

Appels d’offres.

Support complexe.

Opérations internes.

Dans ces marchés, la valeur n’est pas “l’agent répond vite”.

La valeur, c’est :

• l’agent sait quand il peut agir ;

• l’agent sait quand il doit demander validation ;

• l’agent laisse une trace ;

• l’agent respecte les droits ;

• l’agent explique sur quelles sources il s’appuie ;

• l’humain peut reprendre la main sans repartir de zéro.

La gouvernance devient une feature produit.

Et c’est une bonne nouvelle pour les Product Builders.

Parce que ça veut dire que la différence ne se fera pas uniquement sur la puissance du modèle.

Elle se fera sur la capacité à transformer une tâche risquée en workflow opérable.

Prenons un exemple simple.

Un agent qui analyse un dossier d’assurance peut être impressionnant en démo.

Mais en production, la vraie question est :

quelles données a-t-il le droit de voir ?

quels montants peut-il recommander ?

à partir de quel niveau d’incertitude doit-il escalader ?

comment sait-on qu’il n’a pas inventé une règle ?

comment l’équipe qualité peut-elle auditer ses décisions ?

comment l’utilisateur final conteste-t-il une recommandation ?

Là, on n’est plus dans le prompt.

On est dans le design de système.

Et c’est probablement l’un des territoires les plus intéressants pour les builders qui veulent vendre de l’IA à des entreprises réelles.

Pas des agents “magiques”.

Des agents contrôlables.

Si tu travailles déjà sur un agent interne, un outil métier, un assistant support, un workflow documentaire ou une automatisation sensible, c’est typiquement le genre de sujet sur lequel je peux t’aider.

On peut repartir de ton cas réel, cartographier les risques, définir les droits, les étapes de validation, les traces nécessaires, et construire une version qui ne soit pas seulement impressionnante en démo, mais acceptable en production.

Là aussi, tu peux répondre directement à cet email avec ton contexte. Même deux phrases suffisent pour commencer.

La facture IA devient une décision produit, pas un coût technique

Le troisième signal est plus économique.

Et il est tout aussi important.

On parle beaucoup du prix des modèles comme si le sujet se résumait à comparer des tarifs d’API.

Mais dans un vrai produit, le coût IA n’est pas seulement le prix par million de tokens.

C’est aussi :

• le nombre d’appels ;

• la taille du contexte ;

• le niveau de modèle utilisé ;

• les retries ;

• les embeddings ;

• le stockage ;

• l’egress ;

• les outils appelés ;

• les validations humaines ;

• la latence acceptable ;

• le coût d’une mauvaise réponse.

TechRadar a relayé un rapport Google Cloud selon lequel 83 % des organisations devraient revoir leur infrastructure pour maximiser l’opportunité agentique. Le titre est marketing, mais le fond est très concret : entre ambition IA et réalité infra, l’écart devient visible. — TechRadar

Et c’est là que le routing devient important.

Si tu envoies chaque tâche vers le modèle premium par défaut, tu ne construis pas une stratégie IA.

Tu construis une facture.

Un article dev.to sur le routing le formule simplement : toutes les requêtes n’ont pas besoin du même modèle. Certaines tâches demandent un modèle frontier. D’autres peuvent passer par un modèle moins cher, local, spécialisé, ou par une réponse déterministe. — dev.to

Le Product Builder doit donc apprendre à penser l’IA comme un système d’allocation.

Pas :

“Quel est le meilleur modèle ?”

Mais :

“Quel est le bon niveau d’intelligence pour cette étape du workflow ?”

Un exemple très simple :

• classifier une demande entrante ;

• extraire trois champs d’un document ;

• résumer un email ;

• comparer deux contrats ;

• décider si un dossier doit être escaladé ;

• rédiger une réponse client finale.

Ces étapes n’ont pas le même risque.

Elles n’ont pas le même besoin de qualité.

Elles n’ont pas le même coût acceptable.

Elles ne devraient donc pas forcément utiliser le même modèle.

La bonne architecture ressemble moins à un chatbot unique qu’à une chaîne de décisions :

modèle léger ici,

modèle premium là,

règle métier ailleurs,

validation humaine quand le risque dépasse un seuil,

cache quand la réponse est stable,

fallback quand le modèle échoue.

Et cette chaîne doit être compréhensible par le business.

Parce que si personne ne sait pourquoi une tâche coûte 4 centimes, 40 centimes ou 4 euros, personne ne saura scaler le produit correctement.

Le coût utile devient une métrique produit.

Pas juste une métrique infra.

Pour une entreprise, la question ne sera pas :

“Combien coûte GPT ?”

Mais :

“Combien coûte une réponse fiable ?”

“Combien coûte un dossier traité sans erreur ?”

“Combien coûte une qualification commerciale utile ?”

“Combien coûte une décision qui évite deux heures de travail humain ?”

Et là, on revient aux deux premières sections.

Pour piloter le coût utile, il faut connaître le contexte.

Et pour accepter l’automatisation, il faut gouverner l’agent.

Les trois sujets sont liés.

Contexte.

Gouvernance.

Économie.

C’est probablement le triangle le plus important des produits IA en 2026.

Et si on allait plus loin ensemble ?

Si cette édition t’a fait réfléchir, si tu veux challenger une idée ou simplement me partager ton point de vue, réponds directement à cet email. Je lis tout, et je réponds toujours.

👉 Tu peux aussi me retrouver sur LinkedIn : j’y partage ce que je construis autour des Product Builders, des agents IA, des workflows et des nouveaux usages business de l’IA.

👉 Si tu as un projet IA à cadrer, un outil interne à construire, une V1 à lancer ou un workflow métier à automatiser, tu peux aussi me contacter sur LinkedIn. C’est exactement le type de sujet sur lequel j’aime intervenir.

👉 Et si tu veux sponsoriser une prochaine édition de Builder Station, c’est possible. Tu peux consulter le deck sponsor ou me répondre directement à cet email.

🎁 Enfin, si tu veux comprendre comment rendre le savoir d’une entreprise exploitable par des agents IA, j’ai lancé un guide dédié à l’Open Knowledge Format :

Recevoir le guide

Si cette édition t’a apporté quelque chose, le meilleur coup de pouce que tu puisses me donner, c’est de la partager à quelqu’un qui pourrait en faire quelque chose.

Partager

Bonne semaine,

— Milan