Votre agent IA n’a pas besoin de plus de contexte. Il a besoin d’un cerveau en qui il peut avoir confiance.

Imaginez qu’un pager se déclenche à 02:14. Vous ouvrez le manuel opérationnel : il semble parfait, avec des étapes numérotées, un diagramme, des signes évidents que quelqu’un s’en est occupé. Vous suivez l’étape 4, mais cela échoue. En bas de page, vous remarquez la date de la dernière modification : il y a quatorze mois.

Chaque phrase y était correcte au jour où elle a été écrite. Mais il n’y avait aucun signe indiquant qu’elle était obsolète.

C’est là le véritable problème. Ce n’est pas le manque de documents ou la qualité médiocre de ceux-ci. Ce sont des documents qui semblent tout aussi fiables dans leur pire état que le premier jour. Pendant quarante ans, les logiciels ont été livrés en partant du principe que la documentation est de la prose et que c’est au lecteur de l’évaluer. Puis les dépôts de code ont été confiés à des agents incapables de juger quoi que ce soit, qui lisent chaque mot avec une confiance absolue.

Qu’est-ce qui a changé

Un agent d’IA n’a pas de mémoire propre. Il est sans état, et à chaque tour, toute la conversation est renvoyée depuis le début. La documentation d’Anthropic le formule clairement : il faut envoyer l’historique complet de la conversation à chaque fois.

Ainsi, un document d’architecture de 4 000 tokens collé dans le fichier que l’agent charge toujours n’est pas lu une seule fois. Lors d’une session de quarante tours, il est lu quarante fois. Et son chargement peut rendre l’agent moins performant.

La recherche sur le phénomène de perte de contexte menée par Chroma a testé 18 modèles de pointe, parmi lesquels GPT, Claude, Gemini et Qwen, et a révélé que la précision diminue à mesure que la longueur de l’entrée augmente, tombant dans certains cas de 95 % à 60 %. Ce qui devrait faire changer vos habitudes, c’est que ce n’est pas un effet proche de la limite maximale. La dégradation s’est manifestée à chaque niveau de longueur qu’ils ont mesuré. Si ces résultats sont valables, même une fenêtre de un million de tokens commence à souffrir dès cinquante mille tokens, car l’ennemi est le bruit et non la capacité.

Anthropic qualifie cela de budget d’attention : le contexte est une ressource finie dont les retours marginaux diminuent, et l’objectif est d’utiliser l’ensemble le plus réduit possible de tokens à forte signification. Cela ne laisse que deux options médiocres.

• Charger tout. L’agent connaît le système mais est nettement moins performant sur chaque tâche, et chaque modification de document invalide tout le cache des instructions et le réévalue.
• Ne charger rien. L’agent reste performant mais ne sait rien, il doit donc improviser. Il invente une étape de déploiement ou exécute une commande obsolète depuis mars.

Les équipes choisissent l’une ou l’autre, subissent les conséquences, puis passent à l’autre option. C’est à peu près là où se trouve l’industrie aujourd’hui.

Une diagnosis en une phrase existe déjà

En avril 2026, Andrej Karpathy a publié un bref résumé qu’il a appelé un fichier d’idées. Il ne s’agissait ni d’un produit ni d’une bibliothèque. Il esquissait une approche : le modèle transforme les données brutes en un wiki Markdown ordonné et structuré, et à partir de là, les questions sont envoyées vers ce wiki plutôt que vers les sources originales.

La phrase importante qui s’y trouve n’a rien à voir avec l’IA : les humains abandonnent les wikis parce que la charge de maintenance augmente plus rapidement que leur valeur.

Tout ceux qui ont vu un espace Confluence disparaître le reconnaîtront. Les gens ont abandonné, ce n’est pas parce que l’écriture était difficile, mais parce que la maintenance était ardue, et cette maintenance consiste principalement en tâches administratives : mettre à jour le lien, actualiser le résumé, signaler que cette page contredit désormais telle autre, corriger l’index. C’est précisément ce type de travail qui a cessé d’être coûteux, car un LLM ne s’ennuie pas, n’oublie pas une référence croisée et peut traiter quinze fichiers d’un seul coup. Sa division du travail est simple : vous le lisez, l’LLM l’écrit.

L’idée s’est répandue rapidement. Deux mois plus tard, Google Cloud a publié une spécification qui, selon son propre communiqué, formalise le modèle wiki basé sur les LLMs en un format portable et interopérable. Le diagnostic sous-jacent reste celui de Karpathy, et c’est la raison pour laquelle tout cela fonctionne aujourd’hui alors qu’il en était autrement en 2019.

OKF en une demi-minute

OKF, le format Open Knowledge, a été publié par l’équipe Data Cloud de Google Cloud en juin 2026 sous forme de brouillon (v0.2) et constitue explicitement une formalisation de ce modèle. Techniquement, il s’agit d’un répertoire de fichiers Markdown contenant du frontmatter YAML, et c’est tout.

La spécification résume son principe de la manière suivante : tout ce qui peut exécuter la commande cat sur un fichier peut lire OKF, et quiconque est capable d’exécuter git clone sur un répertoire peut le distribuer.

Un seul champ est obligatoire : type. Un fichier ne contenant que ce champ est déjà considéré comme conforme. Aucun registre de schémas, aucune base de données, aucun pipeline d’incorporation, aucune dépendance vis-à-vis d’un fournisseur, et aucun SDK n’est requis.

okf/
  index.md                  ← table of contents
  billing/
    index.md
    invoice-retries.md      ← one file, one answerable question
  flows/
    customer-offboarding.md

Si votre réaction est « donc, un dossier de Markdown », c’est exact. Le format n’est pas l’aspect intéressant, et on peut légitimement objecter qu’un dossier n’a pas besoin de spécification. L’annonce de Google propose une réponse : la wiki de Karpathy, la wiki d’une équipe et l’export du catalogue d’un fournisseur peuvent tous ressembler, avec du Markdown, du frontmatter et des liens croisés, mais aucun n’a été conçu pour coopérer. C’est là toute la raison d’être d’une spécification. Tout le monde est arrivé indépendamment à la même forme, ce qui signifie généralement que cette forme est la bonne, puis chaque implémentation a inventé ses propres noms de champs. Un format transforme plusieurs conventions privées en quelque chose que n’importe quel agent peut lire partout.

L’idée fondamentale : la documentation devient un état

Voici un exemple de document :

---
type: Playbook
title: Invoice retry policy
status: stable                      # draft | stable | deprecated
stale_after: 2026-11-01             # stale when today >= this date
generated: { by: "human:dana", at: 2026-08-10 }
verified:  [{ by: "human:sam",  at: 2026-08-11 }]
sources:
  - resource: services/billing/retry.go
    last_modified: 2026-07-15
not:
  - term: "restart the worker to clear the queue"
    why: "in-flight jobs are lost, they are not re-queued"
    instead: "drain first, then restart"
---

Cinq des champs affichés proviennent de la spécification. Le sixième est le plus important, et il réapparaît ci-dessous.

Un classeur ne fait que stocker des documents. Le cerveau, lui aussi, sait ce qu’il contient, à quel point il est sûr de lui et quels erreurs lui ont appris quelque chose. Les éléments suivants correspondent à cela :

Lisez maintenant ce frontmatter comme le ferait une machine. stale_after représente une date d’expiration. Ce n’est pas un tampon « dernière mise à jour » que les gens doivent interpréter ; il s’agit d’une date absolue qui transforme la notion de péremption en une simple comparaison, today >= stale_after. N’importe quel élément peut effectuer cette vérification : l’agent qui lit le fichier, un job planifié, votre CI.

Arrêtez-vous un instant à cela. La dégradation de la documentation est un problème culturel depuis l’invention des wikis. Les rappels constants, les journées dédiées à la documentation, les audits trimestriels, sans oublier une page « Normes de documentation » elle-même devenue obsolète. Tout cela repose sur la pression sociale, et rien ne peut être imposé. Avec stale_after, la dégradation devient un test échoué, dans la même catégorie qu’une compilation défaillante. Elle passe ou elle échoue, et personne n’a besoin de se sentir mal.

Les autres champs fonctionnent de la même manière. sources énumère les chemins de code décrits par un document, permettant ainsi à un script de répondre enfin à une question que les wikis ne pouvaient jamais résoudre : cette demande de fusion a modifié un fichier que trois documents prétendent expliquer, quelqu’un les a-t-il mis à jour ? verified enregistre ceux qui ont confirmé un document, distinctement de ceux qui l’ont écrit, car, selon les spécifications, celui qui a écrit un concept n’est pas nécessairement celui qui l’a confirmé. Un brouillon rédigé par un agent et l’approbation d’un ingénieur senior sont deux événements distincts, une distinction que la plupart des outils de documentation n’enregistrent jamais. Les niveaux de confiance sont dérivés du préfixe de l’acteur et ne sont pas stockés, car une note stockée est subjective, non portable entre les utilisateurs et devient obsolète.

status: deprecated vous permet de conserver une ancienne définition au lieu de la supprimer. Lorsque deux tableaux de bord diffèrent concernant la notion de « revenus », la cause n’est souvent pas de mauvaises données, mais bien deux définitions différentes, l’une ayant été remplacée discrètement sans que cela ne soit indiqué. Conservez-les toutes les deux, marquez-en une, et les chiffres du dernier trimestre continueront de s’afficher.

C’est là le changement : pas un format plus agréable pour le texte, mais du texte associé à un état pouvant être interrogé. Les documents peuvent être consultés, testés et faire l’objet d’échecs.

L’arithmétique des tokens

Ces valeurs ont été mesurées à partir du jeu d’exemples publié par Google, ce qui permet de les vérifier :

Suivre un fait du début à la fin coûte environ 950 tokens, et ce frais n’est appliqué que pour les requêtes qui en ont besoin. La partie toujours active relève du niveau 0 : 60 tokens, une seule phrase.

Comparez cela à l’approche typique : un guide de 1 600 tokens est ajouté à chaque requête, alors que peut-être seulement une requête sur dix en a besoin. Les connaissances restent les mêmes, la facture moyenne est d’environ un dixième, et le document peut continuer de s’agrandir, car une longueur supplémentaire n’affecte plus les conversations non liées dans le répertoire. La spécification a conçu index.md autour de cet objectif et lui a donné un nom : divulgation progressive — d’abord examiner ce qui existe, puis ouvrir les documents.

Ce que OKF n’est pas

OKF ne fonctionne pas comme une barrière de sécurité. Un fichier Markdown ne peut pas empêcher un agent d’exécuter quelque chose de destructeur. Une application réelle de ces mesures doit se faire au niveau du code, par le biais de listes noires ou d’hooks préalables à l’exécution qui bloquent une action quel que soit le choix du modèle. Peu importe ce dont vous vous souvenez d’autre, ne concluez pas pour autant que le fait d’avoir consigné les dangers signifie que vous êtes protégé.

Ce que OKF vous offre réellement, c’est un agent qui connaît les règles. La spécification définit en outre un type de calcul Attested Computation, dans lequel un agent peut transmettre des paramètres mais ne doit jamais écrire ou modifier le calcul lui-même, ce qui constitue à peu près le mieux possible pour interdire une réécriture de la vérification de sécurité. Suivez cette évolution de près, mais ne vous basez pas dessus pour l’instant : la spécification indique explicitement que cette interface sera reportée à une version ultérieure.

N’oubliez pas non plus qu’il s’agit d’un brouillon. Le passage de v0.1 à v0.2 a déjà entraîné le renommage de deux constructions, donc n’adoptez que les huit champs dont vous avez besoin. Tout renommage ultérieur se fera alors par recherche et remplacement.

Commencez petit, ajoutez des contrôles lorsque c’est utile

Ce n’est pas un projet : c’est un seul fichier.

1. Rédigez un document concernant ce qui a récemment coûté à quelqu’un une après-midi, en y incluant les champs type, title, description et stale_after.
2. Rédigez un fichier index.md qui le liste, avec une colonne indiquant « quand le lire », et ajoutez okf_version: "0.2". L’index racine est l’endroit où ce champ doit se trouver, et selon les spécifications, c’est le seul frontmatter qu’un index peut contenir.

Ajoutez le pointeur à votre fichier toujours actif. Cela coûte environ soixante tokens et contient un chemin ainsi qu’un déclencheur, jamais un résumé, car un résumé augmente à la fois le coût du fichier toujours actif et oblige néanmoins l’agent à ouvrir le fichier.

Cela suffit pour commencer. Étant donné que today >= stale_after n’est qu’une comparaison, l’agent peut l’évaluer dès que le fichier est ouvert. La manière de gérer un document obsolète dépend de vous, ce que la spécification laisse intentionnellement ouvert.

Ajoutez l’automatisation dès qu’une deuxième personne peut invalider votre document sans le lire. C’est là le véritable seuil, et il concerne davantage la taille de l’équipe que la précision. Avec seulement cinq documents, vous vous en rendrez compte, et une vérification de l’expiration côté agent suffit. Au sein d’une équipe, celui qui invalide votre document est par définition quelqu’un qui ne l’a jamais ouvert ; par conséquent, de bonnes intentions ne peuvent pas l’atteindre, il faut donc mettre en place un mécanisme dans le processus de pull request. La version économique consiste en une tâche planifiée qui signale les documents expirés. La version avancée est un contrôle de type gate dans le pull request qui bloque la validation en cas de document expiré et émet une alerte si le code décrit dans le document a été modifié. Commencez par la solution la moins coûteuse.

La version courte

Ce dont a besoin un agent, ce n’est pas d’une fenêtre de contexte plus grande. Il doit savoir où chercher, et tout fichier qu’il ouvre doit indiquer honnêtement son âge. Soixante tokens au préalable, le reste sur demande, ainsi qu’un document qui peut perturber le processus de construction dès qu’il cesse d’être exact, ce qui n’était pas possible auparavant.

Lectures complémentaires : la spécification OKF v0.2 et les exemples associés, l’article de Google Cloud sur ce format, les articles d’Anthropic sur l’ingénierie du contexte, les compétences des agents et le stockage en mémoire des prompts, ainsi que l’étude de Chroma sur la dégradation du contexte.

Lectures relatives

• Notes pratiques : Votre agent de codage n’a pas besoin de plus de contexte. Il a besoin d’une carte. — Guide pratique des Notes pratiques : Votre agent de codage n’a pas besoin de plus de contexte. Il a besoin d’une carte : contrats, vérifications et emplacements pour du code à insérer pour les équipes utilisant ce modèle.
• Notes pratiques : Votre agent de codage n’a pas besoin d’un prompt meilleur — Guide pratique des Notes pratiques : Votre agent de codage n’a pas besoin d’un prompt meilleur : contrats, vérifications et emplacements pour du code à insérer pour les équipes utilisant ce modèle.

Notes pratiques : Israeli Tech Radar 2026-27 : L’ingénierie à l’ère des agents — Guide complet des Notes pratiques : Israeli Tech Radar 2026-27 : L’ingénierie à l’ère des agents : contrats, vérifications et emplacements prévus pour le code destinés aux équipes qui utilisent ce modèle.