Cette semaine, je veux te parler d’un sujet qui va devenir de plus en plus central pour les Product Builders et qui me passionne énormément depuis plusieurs semaines : le contexte.
Pas le contexte au sens vague, façon “mets plus d’infos dans ton prompt”.
Le contexte au sens très concret : les sources, les décisions, les playbooks, les métriques, les contraintes, les règles d’accès, les preuves et les liens qui permettent à un agent IA de travailler correctement.
Depuis quelques mois, on répète beaucoup que les modèles deviennent plus puissants. C’est vrai. Mais dans les entreprises, le problème est souvent ailleurs : le savoir est dispersé, les règles sont implicites, les documents ne sont pas reliés, les agents ne savent pas quoi croire, ni quoi ouvrir ensuite.
Et à mesure que les agents deviennent capables d’agir, cette question devient encore plus importante.
Avant de demander à une IA d’exécuter, il faut lui donner un terrain propre.
Au programme :
Pourquoi j’ai lancé openknowledgeformat.fr
Ce que l’Open Knowledge Format change pour les entreprises
Ce que contient le guide OKF que je te propose
Pourquoi Cloudflare Monetization Gateway est un signal fort pour le web agentique
Ce que ça change pour les Product Builders
Quelques signaux à garder sous le radar cette semaine
Google Cloud a récemment présenté l’Open Knowledge Format, ou OKF.
L’idée est simple à comprendre, mais assez profonde dans ses implications : créer un format ouvert, lisible par les humains et exploitable par les agents, pour représenter la connaissance utile d’une organisation.
Concrètement, OKF s’appuie sur des fichiers Markdown, du frontmatter YAML, des liens, des sources et une logique de graphe. La spécification reste volontairement courte : chaque concept porte au minimum un type, puis peut être enrichi avec les champs nécessaires.
Ce qui m’intéresse ici, ce n’est pas seulement le côté “nouveau standard”.
Le vrai signal, c’est que les agents ont besoin d’un contexte portable.
Aujourd’hui, dans beaucoup d’entreprises, les informations importantes existent déjà :
une offre commerciale dans un Google Doc ;
des objections clients dans un CRM ;
des décisions produit dans Slack ;
des règles métier dans la tête d’un senior ;
des métriques dans un dashboard ;
des templates de réponse dans Notion ;
des procédures dans des fichiers qui ne parlent à personne.
Le problème n’est pas l’absence totale de connaissance.
Le problème, c’est que cette connaissance n’est pas vraiment exploitable par les agents.
Elle est éparpillée. Elle n’a pas toujours de statut clair. Elle n’est pas reliée aux bonnes sources. Elle ne dit pas forcément ce qui est prioritaire, obsolète, validé ou expérimental.
Résultat : on donne à l’agent un dossier flou, puis on s’étonne qu’il produise une réponse floue.
OKF propose une autre logique : transformer cette connaissance en bundle de contexte.
Un bundle peut contenir des playbooks, des personas, des sources, des métriques, des décisions, des templates, un index, un graphe. Pas dans une plateforme magique. Dans un dossier lisible, versionnable, déplaçable.
C’est exactement la thèse que j’ai voulu rendre accessible avec openknowledgeformat.fr.
Le site est pensé comme une ressource pédagogique en français pour comprendre ce que OKF rend possible :
rendre un contexte lisible par les humains ;
le rendre portable entre outils ;
le versionner dans Git ;
le rendre exploitable par Codex, Claude, Gemini ou des agents internes.
Sur le site, je prends un exemple volontairement simple : une relance de devis B2B.
Au départ, tu as des notes d’appels, un export CRM, un PDF de devis, un argumentaire, un email de relance.
Dans un bundle OKF, ces éléments deviennent des fichiers structurés :
playbooks/relance-devis.mdpersonas/dirigeant-pme.mdtemplates/email-relance.mdsources/export-crm-q2.mdmetrics/transformation.md
L’agent ne reçoit plus seulement “un tas de docs”.
Il reçoit des concepts nommés, des liens, des sources, des métriques et une logique de navigation.
Et ça change beaucoup de choses.
Pour une équipe commerciale, ça peut aider à préparer une relance cohérente et sourcée.
Pour une équipe marketing, ça peut aider à produire du contenu sans perdre le positionnement.
Pour une équipe ops, ça peut réduire les allers-retours internes parce que l’agent sait retrouver les procédures et les dépendances.
Pour une grande entreprise, ça peut devenir une couche portable entre silos, documentation interne et agents déjà déployés.
Mon intuition : les entreprises ne vont pas seulement acheter des agents. Elles vont devoir construire, acheter et maintenir des Contextes.
C’est une nuance importante. Et je pense que le Contexte va devenir “un actif”. Mais je reviendrais plus tard sur cette idée qui a énormément d’implication techniques et business.
On ne parle pas seulement de “faire un bon prompt”.
On parle de structurer ce que l’entreprise sait pour que ses agents puissent travailler avec moins d’ambiguïté.
J’ai donc lancé openknowledgeformat.fr avec deux objectifs :
expliquer OKF simplement aux entreprises francophones ;
commencer à identifier les équipes qui veulent créer leurs premiers Contextes exploitables.
J’ai aussi préparé un guide OKF pour t’aider à comprendre le format, prioriser les documents à structurer et créer un premier bundle.
Si le sujet t’intéresse, tu peux le récupérer ici : recevoir le guide OKF.
Le guide OKF couvre :
ce qu’est OKF exactement ;
pourquoi le contexte devient stratégique ;
comment créer un premier bundle ;
quels documents structurer en priorité ;
comment rendre un second cerveau exploitable par les agents ;
comment connecter ce bundle à Codex, Claude ou Gemini.
Mon objectif est simple : aider les entrepreneurs, PME, équipes produit, équipes ops et organisations plus complexes à créer leurs premiers Contextes avec les premières bonnes pratiques.
Pas un énorme programme de transformation.
Un premier bundle utile, clair, versionnable, sourcé, que des humains peuvent comprendre et que des agents peuvent exploiter.
Tu peux récupérer le guide ici : openknowledgeformat.fr.
Et si tu travailles déjà sur un sujet de ce type dans ton entreprise, réponds à cet email. Ça m’intéresse beaucoup de voir les cas réels : commercial, support, appels d’offres, knowledge management, product ops, documentation interne, conformité, formation.
C’est une version 1 que je compte agrémenter et améliorer au fil de mes travaux et de l’évolution du standard. Si vous avez des remarques je suis bien évidemment preneur.
Deuxième signal de la semaine : Cloudflare a annoncé le Monetization Gateway.
Là aussi, le sujet peut avoir l’air très infra au premier regard.
Cloudflare explique vouloir permettre à ses clients de facturer n’importe quelle ressource protégée par Cloudflare : page web, dataset, API ou outil MCP. Le tout avec des paiements réglés en stablecoins via le protocole x402, et une vérification du paiement à l’edge.
Dit autrement : Cloudflare veut rendre possible la facturation à l’usage pour des ressources que des agents peuvent consommer directement.
Et ça raconte quelque chose de très important.
Le web des humains était construit autour de l’attention.
Tu publiais une page. Un humain venait. Il voyait une pub, s’abonnait, achetait, cliquait, remplissait un formulaire.
Mais un agent ne se comporte pas comme un humain.
Il peut lire une page une fois, extraire ce dont il a besoin, appeler une API, consommer un dataset, utiliser un outil MCP, puis repartir.
Il ne “voit” pas une bannière publicitaire.
Il n’a pas forcément envie de prendre un abonnement mensuel pour chaque micro-ressource.
Il a besoin d’accéder, payer, exécuter, repartir.
Si les agents deviennent des utilisateurs du web, il faut une économie pensée pour des requêtes, pas seulement pour des sessions humaines.
C’est pour ça que je trouve cette annonce intéressante.
Cloudflare ne dit pas seulement “voici un nouveau module de paiement”.
Cloudflare pose une brique de marché : comment un propriétaire de contenu, de donnée, d’API ou d’outil peut décider qui accède, à quel prix, et dans quelles conditions.
Et ce n’est pas isolé.
Le même jour, Cloudflare a aussi détaillé de nouvelles options pour gérer le trafic IA : distinguer Search, Agent et Training, donner plus de contrôle aux propriétaires de sites, et préparer de nouveaux defaults à partir du 15 septembre 2026 pour certains types de trafic automatisé.
Ce que je retiens :
un agent qui indexe n’a pas la même valeur qu’un agent qui agit ;
un crawler d’entraînement n’a pas le même contrat implicite qu’un moteur de recherche ;
une API appelée par un agent peut être facturée autrement qu’un SaaS classique ;
un outil MCP peut devenir une ressource monétisable ;
les sites vont devoir formuler une vraie politique d’accès pour les agents.
En clair : le web agentique ne va pas seulement demander de meilleurs modèles.
Il va demander des compteurs, des droits, des prix, des logs, des politiques d’accès, des preuves d’usage.
Plus haut quand je te parlais d’OKF, cela répondais à cette question : qu’est-ce que l’agent doit comprendre ?
Cloudflare Monetization Gateway répond à une autre question : comment l’agent accède et paie ce qu’il consomme ?
Ce sont deux couches différentes, mais elles vont dans la même direction.
Le web et l’entreprise deviennent des environnements où les agents doivent pouvoir lire, décider, payer, citer, vérifier, agir.
Pour un Product Builder, je vois trois conséquences très concrètes.
Jusqu’ici, beaucoup de projets IA commencent par :
“On va brancher un modèle sur nos docs.”
Puis l’équipe découvre que les docs sont incomplètes, contradictoires, mal nommées, pas à jour, pas sourcées.
Le travail intéressant commence donc avant le modèle.
Il faut choisir les documents utiles. Nommer les concepts. Séparer ce qui est validé de ce qui est brouillon. Relier les sources. Créer des index. Rendre le tout maintenable.
C’est du travail produit.
Pas seulement du prompting.
Le Product Builder qui sait faire ça devient précieux, parce qu’il sait transformer une masse documentaire en système exploitable.
Un agent qui agit pour un utilisateur ne devrait pas avoir les mêmes droits qu’un crawler d’entraînement.
Un agent interne n’a pas les mêmes droits qu’un agent externe.
Un dataset premium ne devrait pas être consommé gratuitement par défaut.
Une API critique doit pouvoir être appelée, tarifée, surveillée, limitée.
Ça veut dire qu’un bon produit IA ne sera pas seulement une interface.
Ce sera aussi un ensemble de règles :
qui peut accéder ;
pour quel usage ;
avec quelle limite ;
à quel prix ;
avec quelle trace ;
avec quelle possibilité de révocation.
Les modèles vont continuer à progresser.
Mais à mesure qu’ils deviennent plus accessibles, la différence se déplace ailleurs :
qualité du contexte ;
fraîcheur des sources ;
politiques d’accès ;
vérification des sorties ;
coût par résultat utile ;
capacité à maintenir le système dans le temps.
C’est moins spectaculaire qu’une démo.
Mais c’est exactement là que les projets IA d’entreprise vont se jouer.
Et c’est une bonne nouvelle pour les Product Builders.
Parce que notre rôle n’est pas seulement de choisir un outil. C’est de transformer une technologie en système utilisable, vendable, maintenable.
→ Les evals deviennent la colonne vertébrale des agents : plusieurs signaux récents vont dans la même direction : un agent long, utile et actionnable doit être testé avec des datasets, des sandboxes et des vérifications métier. Sinon, il reste une démo difficile à industrialiser. — Harbor x LangChain
→ L’IA devient une ligne de marge : Microsoft rationalise ses coûts IA, les équipes parlent de routing multi-modèles, et les produits sérieux commencent à arbitrer coût, latence, qualité et fiabilité. Le sujet n’est plus “quel est le meilleur modèle ?”, mais “quel modèle pour quel résultat utile ?” — TechCrunch
→ Les projets IA cassent souvent sur l’organisation : ajouter une IA sur des silos, des validations lentes et des responsabilités floues ne règle pas le problème. Ça l’accélère. Avant de parler automatisation, il faut souvent clarifier le workflow, les sources de vérité et les décisions. — X
→ Open AI vient de sortir ChatGPT 5.6 avec plusieurs modèles : Sol, Terra et Luna. De nouveaux modèles frontières qui excellent encore plus sur le code, la cyber… A tester dès maintenant !
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 :
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.
Bonne semaine,
— Milan
Aucun post
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.