Après les prompts, la prochaine mine d’or de l’IA : ton contexte métier

Depuis deux ans, on a surtout regardé les modèles.

GPT, Claude, Gemini, Mistral, DeepSeek.

Qui raisonne le mieux ? Qui code le mieux ? Qui coûte le moins cher ? Qui gagne le benchmark du moment ?

Mais cette semaine, le signal le plus important n’est pas un nouveau modèle.

C’est un dossier Markdown.

Google Cloud a présenté l’Open Knowledge Format, un standard ouvert pour structurer la connaissance métier dans des fichiers lisibles à la fois par les humains et par les agents IA.

Dit comme ça, ça a l’air presque ennuyeux.

En réalité, c’est probablement l’un des signaux les plus importants du moment : la valeur ne se déplace pas seulement vers les agents. Elle se déplace vers le contexte que les agents peuvent vraiment utiliser.

Au programme :

• 🧠 Pourquoi le contexte devient le vrai produit dans l’ère des agents

• Pourquoi les fichiers Markdown, OKF, DESIGN.md et les wikis versionnés peuvent remplacer une partie des docs internes

• Pourquoi le navigateur perd son monopole comme interface de travail

• Comment auditer ton propre business pour savoir s’il est lisible par un agent

• 📡 OKF, Printing Press, DESIGN.md, Obsidian et le paradoxe de Dan Shipper

Le contexte devient un vrai produit

Un agent sans contexte, c’est un stagiaire brillant à qui tu n’as jamais expliqué ton métier.

Il y a une phrase dans l’annonce de Google Cloud qui résume bien le problème : les modèles progressent, mais ce qui limite leur utilité, c’est souvent l’absence du bon contexte.

Et si tu as déjà utilisé un agent IA sur un vrai projet, tu l’as probablement vécu.

Il sait écrire.

Il sait coder.

Il sait résumer.

Il sait proposer une structure.

Mais il ne sait pas naturellement ce que ton entreprise appelle un “lead qualifié”, quelle règle métier prime en cas de conflit, où se trouve la dernière version d’un process, quelles exceptions ton équipe connaît par expérience, ou pourquoi ce vieux fichier Google Sheets est devenu critique alors que personne ne l’a documenté.

Le problème n’est plus seulement l’intelligence du modèle. Le problème, c’est la lisibilité de ton organisation.

Google appelle son format Open Knowledge Format. La promesse est simple : représenter la connaissance sous forme d’un dossier de fichiers Markdown, avec des métadonnées en YAML au début de chaque fichier.

Pas de runtime compliqué.

Pas de nouveau SaaS obligatoire.

Pas de format propriétaire illisible.

Juste des fichiers.

Un fichier peut décrire une métrique, une table, une API, un runbook, une définition métier, une procédure, une règle, un glossaire, une décision ou un concept. Chaque élément peut être lu par un humain, versionné dans Git, indexé par un moteur de recherche, puis consommé par un agent.

C’est beaucoup moins sexy qu’une démo d’agent qui clique partout à ta place.

Mais c’est exactement ce qu’il manque à la plupart des usages sérieux.

Parce qu’un agent qui agit dans le flou produit du flou plus vite.

Un agent qui agit avec une base de connaissance claire peut commencer à devenir un vrai système de travail.

Selon moi, même si OKF n’en est encore qu’à ses débuts, je pense que ce travail “contextuel” va devoir être mis en place par les Product Builders dans les prochains mois.

Ce sujet me passionne vraiment. Si toi aussi, n’hésite pas à me contacter !

La documentation n’est plus seulement faite pour les humains

Pendant longtemps, la doc interne avait un rôle assez simple : aider les humains à se souvenir.

On mettait ça dans Notion, Confluence, Google Drive, un PDF, parfois Obsidian, parfois un dossier de fichiers un peu oublié.

Le problème, c’est que cette documentation était souvent écrite comme une archive.

Utile quand quelqu’un sait déjà quoi chercher.

Beaucoup moins utile quand un agent doit décider quoi lire, dans quel ordre, avec quelle règle métier, et comment relier plusieurs morceaux d’information.

La documentation de demain doit être actionnable par des agents, pas seulement lisible par des humains.

C’est là que des formats comme OKF, DESIGN.md, AGENTS.md ou les wikis Markdown deviennent intéressants.

Google avait déjà poussé DESIGN.md dans Stitch : un fichier qui décrit les règles visuelles d’un produit pour que l’IA génère des interfaces cohérentes. Des projets comme getdesign.md vont dans le même sens : transformer une identité visuelle en règles textuelles que les agents de code peuvent utiliser.

AGENTS.md documente comment un agent doit travailler dans un repo.

DESIGN.md documente comment il doit respecter une direction visuelle.

OKF documente le contexte métier ou analytique qu’il doit comprendre.

Même logique partout : on transforme le savoir implicite en fichiers portables que les agents peuvent relire, citer, modifier et utiliser.

Et c’est là que le Product Builder a une carte énorme à jouer.

Parce que les entreprises n’ont pas seulement besoin de “mettre de l’IA” dans leurs process.

Elles ont besoin de rendre leurs process compréhensibles par l’IA.

Ce n’est pas le même métier.

Dans un cas, tu branches un outil.

Dans l’autre, tu restructures la connaissance, les règles, les permissions, les formats de sortie et les boucles de validation.

C’est beaucoup plus proche du product thinking que du simple prompt engineering.

Le navigateur perd son monopole

Selon moi, c’est un très gros shift qui s’annonce !

Dans un épisode récent de Lenny’s Podcast, Dan Shipper défend une idée intéressante : une partie du travail va se déplacer vers des environnements comme Codex ou Claude Code, où les agents manipulent les tâches, les fichiers, les apps et le contexte à ta place.

Je ne pense pas que ça veuille dire que le navigateur disparaît.

Mais je pense que son rôle change.

Aujourd’hui, beaucoup de workflows ressemblent encore à ça :

1. ouvrir un onglet

2. chercher une information

3. copier-coller dans un autre outil

4. reformater

5. demander à l’IA de résumer

6. recoller ailleurs

7. vérifier

8. recommencer

Le navigateur est l’interface centrale parce que l’humain est encore celui qui navigue.

Mais si l’agent devient celui qui lit, cherche, extrait, compare et agit, l’interface centrale n’est plus forcément la page web.

Elle devient la tâche.

Ou le fichier.

Ou le contexte versionné.

Ou la commande que l’agent sait exécuter.

C’est exactement ce que montre Printing Press : transformer une API, un site ou un projet en CLI, skill et serveur MCP utilisables par des agents. L’idée n’est pas de rendre un site plus joli. L’idée est de rendre un service manipulable par un agent sans qu’il perde du temps à cliquer partout.

On passe d’un web pensé pour des humains qui regardent à un web que des agents doivent pouvoir opérer.

Et ça change la manière de construire.

Si ton produit n’expose aucune structure claire, aucune action documentée, aucune règle lisible, aucun format stable, il devient difficile à utiliser pour un agent.

Même s’il est beau.

Même s’il est utile.

Même s’il marche très bien pour un humain.

Dans l’ancien monde, l’enjeu était : “est-ce que mon utilisateur comprend mon interface ?”

Dans le nouveau, une deuxième question arrive : “est-ce qu’un agent peut comprendre mon système sans halluciner le mode d’emploi ?”

Ce que ça change pour toi

🟢 Maintenant : audite ton contexte

Choisis un workflow que tu fais souvent : préparer une proposition commerciale, analyser des leads, produire une newsletter, gérer un ticket support, qualifier un appel, faire une recherche marché.

Puis demande-toi :

• Où sont les informations nécessaires ?

• Quelles définitions métier l’agent doit connaître ?

• Quelles règles ne sont écrites nulle part ?

• Quels exemples montrent un bon résultat ?

• Qu’est-ce que l’agent peut faire seul ?

• Qu’est-ce qui doit rester validé par toi ?

Si les réponses sont dispersées dans 12 outils, le problème n’est pas encore ton agent. C’est ton système de contexte.

🟡 À surveiller : les formats agent-readable

OKF, DESIGN.md, AGENTS.md, les dossiers Markdown, les skills, les MCP, les CLIs agent-native : tout ça raconte le même mouvement.

Les agents ont besoin d’une couche de connaissance stable entre eux et le chaos de tes outils.

Ceux qui sauront produire cette couche pour une équipe ou un client vont vendre autre chose qu’une automatisation : ils vont vendre une infrastructure de travail.

⚪ Pas encore : migrer toute ta documentation

Ne transforme pas toute ton entreprise en repo Markdown cette semaine.

Commence petit.

Un workflow.

Un dossier.

Un format.

Une boucle de validation.

Le but n’est pas d’avoir une belle architecture de connaissance. Le but est qu’un agent puisse faire mieux une tâche réelle, avec moins d’ambiguïté.

🛠️ À tester cette semaine : ton mini-OKF perso

Tu peux tester cette idée sans attendre que toute l’industrie se mette d’accord sur un standard.

Crée un dossier knowledge/ dans un projet.

Dedans, ajoute 5 fichiers Markdown :

knowledge/
  business.md
  audience.md
  offers.md
  workflow-newsletter.md
  rules.md

Dans chaque fichier, commence par quelques métadonnées simples :

---
type: workflow
title: Newsletter hebdomadaire
owner: Milan
last_updated: 2026-06-17
tags: [newsletter, editorial, ai]
---

Puis documente le contenu comme si tu briefais un excellent assistant :

• le contexte

• les règles

• les exemples de bon résultat

• les erreurs à éviter

• les sources fiables

• les validations nécessaires

Ensuite, donne ce dossier à ton agent et demande-lui de travailler uniquement à partir de cette base.

À tester : prends une tâche que tu délègues déjà à l’IA et ajoute-lui une base de contexte minimale en Markdown. Compare le résultat avant / après. Tu vas vite voir si ton problème était le modèle ou la mémoire autour du modèle.

🔮 Quelques découvertes à ne pas louper

→ Printing Press : le projet transforme des sites, APIs ou communautés en CLIs, skills et serveurs MCP pour agents. Le signal : demain, un bon produit ne sera pas seulement agréable à utiliser par un humain, il devra aussi être facile à opérer par un agent. — Printing Press

→ Dan Shipper chez Lenny : Dan défend une thèse contre-intuitive : plus d’automation peut créer plus de travail, parce que chaque agent a besoin d’un humain pour cadrer, juger et gouverner. Pour les Product Builders, c’est plutôt une bonne nouvelle : le skill rare devient la capacité à structurer le travail, pas seulement à cliquer dans les outils. — Lenny’s Newsletter

Le truc que je retiens cette semaine, c’est qu’on a peut-être passé trop de temps à demander “quel agent utiliser ?”

La meilleure question est peut-être : “qu’est-ce que mon agent peut vraiment comprendre de mon business ?”

Et souvent, la réponse pique un peu.

Si un sujet t’a parlé, si tu veux challenger une idée ou juste dire que tu étais là — réponds directement à cet email. Je lis tout et je réponds à tout.

Et si tu as un projet à développer — une app, un outil interne, une V1 à finaliser — c’est exactement pour ça que je suis là. Un message en réponse à cet email suffit pour qu’on en parle.

Si tu veux sponsoriser les prochaines éditions c’est possible. Je te laisse consulter le deck.

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 en ferait quelque chose 👇

Share

Tu peux aussi me retrouver sur LinkedIn pour suivre ce que je construis en dehors des éditions.

Bonne semaine,

— Milan