Les articles de recherche ont besoin de fichiers d’assertions lisibles par les agents

Le 15 mai 2026, Arquimedes Canedo a proposé paper.json : un fichier JSON compagnon qui permet à un article de recherche d’exposer, à côté du PDF, des identifiants d’assertions stables, des limites de portée explicites, des commandes de reproduction par figure et des identifiants de définitions stables.¹

Ce petit fichier révèle un problème beaucoup plus vaste.

Les agents de recherche lisent désormais des articles, en extraient des assertions, citent des sources, reproduisent des figures, construisent des travaux de suivi et résument la portée des résultats.¹ La prose reste utile aux lecteurs humains. Mais seule, elle laisse aux agents trop de marge pour citer la mauvaise sous-assertion, généraliser au-delà des preuves, inventer des commandes de reproduction ou reconstituer une définition de mémoire.

Les articles de recherche ont besoin de fichiers d’assertions lisibles par les agents. Un article devrait fournir aux agents une interface structurée indiquant ce que l’article affirme, ce qu’il n’affirme pas, la signification des termes clés et la façon dont les preuves se rattachent aux figures et au code.

TL;DR

Les fichiers d’assertions lisibles par les agents transforment un article limité à la prose en un article accompagné d’une surface de preuves adressable. Le PDF reste l’objet destiné aux humains. Le fichier d’assertions donne aux agents des identifiants stables, des limites de portée, des définitions et des commandes de reproduction.

La proposition paper.json défend cette idée avec un schéma concret et un dépôt d’exemple. Le brouillon décrit cinq conventions : des identifiants d’assertions stables, une liste explicite de ce qui n’est pas affirmé, des commandes shell exactes pour chaque figure, une conformité minimale viable via un seul fichier JSON écrit à la main, et des identifiants de définitions stables.¹ Le dépôt compagnon contient paper.json, schema.json, validator.py, resolve.py, le PDF et la source Typst.²

L’écosystème plus large de la recherche sur les agents va dans le même sens. Argus traite la recherche approfondie comme un assemblage de preuves plutôt que comme une recherche parallèle brute.³ ACDL donne aux contextes d’agents un langage de description formel.⁴ Les travaux sur l’exploration montrent que les agents ont besoin de points de contrôle vérifiables avant d’agir.⁵ Les recherches sur les architectures conçues par des agents renforcent l’enjeu de la reproductibilité au niveau de l’article lorsque des agents génèrent des assertions scientifiques.⁶

La règle pratique est simple : publier la prose pour les humains et le fichier d’assertions pour les agents.

Points clés

Pour les auteurs d’articles : - Ajoutez des identifiants stables pour les assertions, les définitions, les théorèmes, les figures et les travaux de suivi. - Rédigez les limites de portée comme des champs à part entière, pas comme une prose défensive reléguée en fin d’article.

Pour les évaluateurs : - Vérifiez que les assertions lisibles par machine correspondent à l’article, pas seulement que le schéma est valide. - Traitez les fichiers d’assertions obsolètes ou exagérés comme des défauts présentant un risque de citation.

Pour les concepteurs d’agents de recherche : - Récupérez le fichier d’assertions avant de résumer, citer, reproduire ou prolonger un article. - Citez les identifiants d’assertions et de définitions lorsque la tâche dépend d’une portée exacte.

Pour les revues et les dépôts : - Acceptez un fichier simple à côté du PDF avant de demander aux auteurs d’adopter une plateforme complète. - Validez automatiquement la structure et laissez l’examen sémantique aux humains et aux agents spécialisés.

Pourquoi les articles en prose échouent-ils avec les agents de recherche ?

La prose académique condense les preuves dans un récit.

Ce récit aide les humains. Un lecteur attentif peut suivre les nuances, comparer les sections, déduire quel résultat soutient quelle assertion et repérer l’endroit où l’article s’arrête. Les agents traitent souvent les articles autrement : ils parcourent, segmentent, récupèrent, citent, résument et composent de nouveaux artefacts sous contraintes de temps et de contexte.

Des modes d’échec prévisibles apparaissent alors.

Canedo nomme directement plusieurs de ces échecs : les sous-assertions n’ont pas d’identifiants de citation plus précis que l’article entier, les dépassements de portée passent dans les résumés en prose, et les commandes de figures se trouvent souvent hors de l’article, dans des dépôts de code.¹

Il ne s’agit pas de remplacer l’article. Il faut ajouter une interface qui rend ses assertions plus faciles à adresser.

Que devrait contenir un fichier d’assertions ?

Un fichier d’assertions lisible par les agents devrait exposer les éléments que les agents utilisent le plus souvent de travers.

L’exemple complet de paper.json inclut une version provisoire, l’URL du dépôt, les métadonnées des auteurs, le résumé, les assertions, les exclusions de portée, les commandes de reproductibilité et une validation adossée à un schéma.² Son schéma exige des champs centraux comme id, title, version, status, authors, abstract, claims, does_not_claim et reproducibility.²

La structure ne prouve pas la vérité. Elle rend la vérité vérifiable.

Cette distinction compte. Le fichier paper.json précise explicitement qu’un validateur réussi ne peut pas prouver la justesse sémantique, l’exhaustivité ni la qualité de reproduction des figures.² Un fichier d’assertions obsolète peut faire plus de mal qu’une absence de fichier, car les agents peuvent faire davantage confiance à un champ bien ordonné qu’à une prose plus ambiguë.

La norme doit donc comporter deux niveaux :

1. Validation structurelle : le fichier peut-il être analysé, contient-il les champs requis et préserve-t-il les identifiants déclarés ?
2. Revue sémantique : le fichier représente-t-il fidèlement l’article ?

Les auteurs peuvent automatiser le premier niveau. Les évaluateurs doivent assumer le second.

Pourquoi les identifiants d’assertions stables comptent-ils ?

Les agents citent trop largement lorsque la seule unité adressable est l’article entier.

Un article peut contenir une assertion de méthode, une assertion d’évaluation, une assertion de limitation, une assertion de benchmark et une assertion de travail de suivi. Un lecteur humain peut citer l’article et expliquer quelle partie importe. Un agent transforme souvent cette citation de l’article entier en vague jeton d’autorité.

Les identifiants d’assertions stables donnent aux agents une cible plus précise.

Le brouillon de Canedo rapporte des éléments pilotes sur la récupération par identifiants d’assertions. Dans la condition de récupération conceptuelle la plus difficile, les agents utilisant les assertions JSON ont obtenu en moyenne 1,20 sur 2, contre 0,60 sur 2 pour les agents cherchant dans la prose.² L’article présente ce résultat comme une preuve pilote, pas comme une démonstration à grande échelle.²

Cette prudence renforce la proposition. L’enjeu n’est pas de prétendre que le premier pilote a tranché la question. Il est de demander aux auteurs de créer un meilleur objet d’évaluation.

Les identifiants d’assertions permettent aux évaluateurs de poser des questions plus nettes :

• L’agent a-t-il cité C1 ou l’article entier ?
• Le résumé a-t-il conservé le qualificatif de C2 ?
• Le système en aval s’est-il appuyé sur C3 sans vérifier la commande ?
• L’agent a-t-il confondu un identifiant de définition avec une assertion de résultat ?

Ces questions valent mieux que : « le résumé semblait-il correct ? »

Pourquoi les limites de portée ont-elles besoin de leur propre champ ?

Les agents exagèrent souvent les articles parce que les limites restent enfouies dans la prose.

Un article peut dire que son benchmark couvre cinq tâches, que sa méthode nécessite un environnement précis ou que son résultat ne se généralise pas au-delà d’un dispositif contrôlé. Un lecteur humain peut garder cette nuance en tête. Un résumé produit par un agent peut perdre le qualificatif après une seule réécriture.

Un champ explicite does_not_claim[] rend les limites de portée visibles avant réutilisation.

La proposition paper.json liste plusieurs exclusions pour son propre travail. Elle n’affirme pas que C1, C2 ou C3 sont prouvées, n’affirme pas que le validateur garantit la justesse sémantique, n’affirme pas que la convention résout la lecture par agents et n’affirme pas une compatibilité avec toutes les normes de métadonnées savantes.²

Cette liste donne aux agents quelque chose d’utile : des limites qu’ils peuvent citer.

Les champs de portée aident aussi les évaluateurs. Si un résumé d’agent dit que « paper.json prouve que les identifiants d’assertions améliorent la précision des citations par agents », l’évaluateur peut comparer cette phrase au champ does_not_claim[] et signaler l’extrapolation. Sans champ dédié, il doit inférer la portée à partir de la prose.

Pourquoi les commandes de figures devraient-elles accompagner les assertions ?

La reproduction échoue souvent au niveau de la commande.

Beaucoup d’articles renvoient vers un dépôt. La commande exacte d’une figure peut se trouver dans un script, une cible Make, un notebook, une note de README ou nulle part de façon évidente. Un agent peut fouiller le dépôt et assembler une commande qui paraît plausible. Les commandes plausibles créent une confiance dangereuse lorsqu’elles n’ont jamais été exécutées.

Un fichier d’assertions lisible par les agents devrait lister directement les commandes de reproduction.

L’exemple complet de paper.json inclut des commandes pour générer le validateur, valider paper.json par rapport à paper.typ et compiler l’article Typst en PDF.² Le brouillon de Canedo rapporte des éléments pilotes montrant que les commandes de reproduction fournies par JSON ont amélioré la récupération des commandes de figures par rapport aux sections de méthodes en prose qui pointent vers un dépôt.²

Le champ de commande doit rester modeste :

Les agents ne doivent pas considérer un champ de commande comme un succès. Ce champ leur donne une cible à exécuter, enregistrer et rapporter.

Où placer les définitions ?

Les définitions peuvent causer plus de dégâts que les assertions.

Une assertion erronée échoue généralement sur une phrase. Une définition erronée contamine toutes les phrases ultérieures qui utilisent le terme. Les agents qui reconstruisent les définitions depuis la prose peuvent créer un vocabulaire qui paraît propre à l’article tout en s’éloignant du sens donné par l’auteur.

Des identifiants de définitions stables réduisent ce risque.

La cinquième convention de Canedo donne aux définitions des identifiants stables, et le brouillon soutient que les définitions rédigées par les auteurs devraient primer sur les définitions reconstruites par les agents lors des réutilisations ultérieures.¹ Le résolveur du dépôt prend en charge des fragments comme #C1, #D1, #T1 et #F1, qui associent les identifiants à des assertions, définitions, théorèmes et éléments de suivi.²

Ce mécanisme compte pour les systèmes en aval.

Les fichiers d’assertions devraient rendre les termes adressables. Les agents devraient citer ou résoudre les définitions avant de les appliquer.

Comment les agents de recherche devraient-ils utiliser les fichiers d’assertions ?

Les agents ont besoin d’un protocole de lecture.

Avant de résumer ou de citer un article, un agent de recherche devrait :

1. Récupérer le fichier d’assertions de l’article lorsqu’il existe.
2. Valider la structure du fichier.
3. Résoudre l’assertion, la définition, la figure, le théorème ou l’identifiant de suivi demandé.
4. Recouper l’élément résolu avec le PDF lorsque la tâche a des enjeux réels.
5. Préserver les limites de portée dans chaque résumé.
6. Exécuter les commandes de reproduction uniquement dans un bac à sable approprié.
7. Rapporter la sortie des commandes, les fichiers manquants et les vérifications échouées comme des preuves.
8. Revenir à la prose seulement lorsque le fichier d’assertions ne contient pas l’élément nécessaire.

Ce protocole devrait produire un dossier d’examen :

L’objectif n’est pas d’ajouter de la paperasse. Il est de réduire les citations sans appui.

En quoi l’écosystème plus large de la recherche sur les agents va-t-il dans le même sens ?

Les recherches récentes sur les agents reviennent sans cesse au même thème : les agents ont besoin de surfaces de preuves structurées, pas de davantage de fluidité sans ancrage.

Argus traite la recherche approfondie comme un assemblage de preuves. Le système utilise un Searcher et un Navigator ; le Navigator suit un graphe de preuves partagé et répartit les recherches vers les éléments de preuve manquants.³ Cette conception renforce le besoin d’articles exposant des éléments de preuve que les agents peuvent assembler.

ACDL cible la description des contextes. Les auteurs soutiennent que les systèmes d’agents ont besoin d’un langage précis et lisible pour décrire l’évolution des prompts et de l’historique d’interaction au fil des étapes.⁴ Les fichiers d’assertions jouent un rôle parallèle au niveau de l’article : ils décrivent comment les assertions, définitions et commandes de l’article doivent entrer dans le contexte de l’agent.

Les recherches sur l’exploration ajoutent un autre angle. « Look Before You Leap » introduit Exploration Checkpoint Coverage, une métrique vérifiable permettant de savoir si un agent découvre les états, objets et affordances clés avant d’agir.⁵ Les agents de recherche ont besoin de la même discipline avant de citer ou réutiliser un article. Ils devraient découvrir les assertions, définitions, limites et commandes avant d’agir.

AIRA relève encore les enjeux. L’article AIRA-Compose et AIRA-Design rapporte une recherche d’architectures multi-agents qui propose de nouvelles architectures de modèles de fondation et des gains en aval par rapport aux références.⁶ Si des agents peuvent générer des assertions scientifiques de conception, les articles qui décrivent ces assertions ont besoin de limites lisibles par machine et de points de reproduction.

ARIS nomme un échec qui correspond à toute cette catégorie : les agents de recherche de longue durée peuvent produire des succès plausibles mais non étayés lorsque le soutien probant reste incomplet, mal rapporté ou hérité du cadrage de l’exécuteur.⁷ Les fichiers d’assertions laissent moins de place aux agents de recherche pour hériter d’un cadrage non étayé depuis la seule prose.

Le motif est constant. Les agents de recherche sérieux ont besoin d’objets de preuve explicites.

Que peuvent publier les auteurs dès maintenant ?

Les auteurs n’ont pas besoin d’attendre l’approbation des revues.

La première version peut vivre à côté de l’article :

{
  "id": "my-paper",
  "title": "My Paper Title",
  "version": "0.1.0",
  "status": "draft",
  "repository": "https://github.com/example/my-paper",
  "claims": [
    {
      "id": "C1",
      "statement": "The method improves retrieval accuracy on benchmark X under condition Y.",
      "evidence": ["figure-2", "table-1"]
    }
  ],
  "does_not_claim": [
    "The method improves retrieval accuracy outside benchmark X."
  ],
  "definitions": [
    {
      "id": "D1",
      "term": "retrieval accuracy",
      "definition": "The percentage of queries whose top-ranked result matches the labeled answer."
    }
  ],
  "reproducibility": {
    "environment": "Python 3.11",
    "commands": ["python scripts/reproduce_figure_2.py"]
  }
}

Le premier fichier devrait répondre à cinq questions :

1. Quelles assertions exactes les agents peuvent-ils citer ?
2. Quelles assertions les agents devraient-ils refuser d’inférer ?
3. Quelles définitions doivent rester stables ?
4. Quelles commandes reproduisent les preuves ?
5. Quelle version de la surface d’assertions l’agent a-t-il lue ?

Ce minimum donne aux agents un point de départ plus sûr. Il donne aussi aux évaluateurs un diff concret lorsque l’article change.

Que devraient vérifier les évaluateurs et les plateformes ?

Les évaluateurs ne devraient pas valider machinalement un fichier JSON valide.

Ils devraient comparer le fichier à l’article.

Les plateformes peuvent automatiser une partie de ce travail.

Elles peuvent vérifier la syntaxe JSON, les champs requis, le format des identifiants, les doublons, les références manquantes, l’accessibilité des URL, la présence de commandes et les métadonnées de version. Elles peuvent aussi demander à un agent de comparer le fichier d’assertions à la prose et de produire un dossier d’examen pour les humains.

La revue humaine décide toujours du sens. L’automatisation ne fait que rendre la dérive visible.

Que devrait refuser la norme ?

Les fichiers d’assertions lisibles par les agents doivent rester assez petits pour être adoptés et assez stricts pour compter.

Trois tentations doivent être refusées.

D’abord, refuser la dépendance à une plateforme. Un fichier placé à côté du PDF vaut mieux qu’une nouvelle plateforme qu’aucun auteur n’adopte. Le brouillon de Canedo soutient que la conformité minimale viable devrait exiger un seul fichier JSON écrit à la main, pas de nouveaux outils ni d’inscription à une plateforme.¹

Ensuite, refuser la fausse certitude. Un schéma peut valider une forme. Il ne peut pas prouver une vérité sémantique. Les fichiers d’assertions devraient dire ce qu’ils prouvent, ce qu’ils ne prouvent pas et comment les évaluateurs peuvent vérifier la dérive.

Enfin, refuser la stratégie cachée. Les agents ont besoin de points d’ancrage probants, pas de prompts privés d’auteurs. Un fichier d’assertions public devrait exposer assertions, définitions, limites et commandes. Il ne devrait pas exposer de notes confidentielles de relecture, de grilles d’évaluation cachées, d’identifiants ni de chemins de données non publiées.

Les bonnes normes réduisent l’ambiguïté sans demander de faire confiance à une mécanique secrète.

La norme digne de ce nom

L’article digne de ce nom ne se contente pas de convaincre un lecteur humain. Il donne aux futurs lecteurs, agents, évaluateurs et personnes qui prolongeront ce travail une manière de le réutiliser sans l’étirer.

Un fichier d’assertions lisible par les agents devrait rendre l’article plus fiable en rendant ses limites plus faciles à inspecter.

La norme est simple :

• Donner une adresse à chaque assertion importante.
• Donner un champ à chaque limite de portée.
• Donner un identifiant stable à chaque définition clé.
• Donner une commande exacte à chaque figure reproduite.
• Donner à chaque agent une raison de citer l’article avec précision.

Les agents de recherche continueront à lire des articles. Les auteurs peuvent les laisser extraire des éléments de la prose, ou leur fournir une surface conçue pour les preuves.

La seconde voie produit de meilleures citations, des résumés plus sûrs et moins d’assertions plausibles sans ancrage fiable.

Résumé rapide

Les articles de recherche ont besoin de fichiers d’assertions lisibles par les agents parce que les agents résument, citent, testent et réutilisent déjà des travaux académiques. La prose seule leur laisse trop de marge pour citer des articles entiers au lieu de sous-assertions, exagérer la portée, inventer des commandes ou faire dériver les définitions.

paper.json offre un point de départ pratique : identifiants d’assertions stables, exclusions de portée explicites, commandes par figure, adoption minimale viable via un fichier JSON unique, et identifiants de définitions stables.¹ Son dépôt d’exemple ajoute une validation par schéma, un résolveur et un fichier concret.²

La meilleure première version est réduite : assertions, non-assertions, définitions, commandes de reproduction, métadonnées de version et lien vers le dépôt. Le fichier ne doit pas remplacer l’article. Il doit rendre sa lecture plus sûre pour les agents.

FAQ

Qu’est-ce qu’un fichier d’assertions lisible par les agents ?

Un fichier d’assertions lisible par les agents est un fichier structuré placé à côté d’un article. Il expose les assertions, limites de portée, définitions, commandes de reproduction et métadonnées associées dans un format que les agents peuvent récupérer et citer.

paper.json remplace-t-il le PDF ?

Non. Le PDF reste l’article lisible par les humains. Le fichier d’assertions donne aux agents une surface de preuves adressable afin qu’ils puissent citer et tester les assertions de l’article plus sûrement.

Quel problème paper.json cherche-t-il à résoudre ?

paper.json cible des échecs récurrents de lecture par agents : citations de mauvaises sous-assertions, dépassements de portée, commandes de figures cachées et définitions instables.¹

Un schéma valide prouve-t-il que le fichier d’assertions est correct ?

Non. Un schéma peut valider les champs requis, les identifiants et la structure. Une revue humaine ou menée par un agent spécialisé doit encore vérifier que le fichier d’assertions représente fidèlement l’article.

Que devraient inclure les auteurs en premier ?

Les auteurs devraient commencer par des identifiants d’assertions stables, une section does_not_claim[], des définitions stables, des commandes de reproduction exactes, l’URL du dépôt et une version du fichier d’assertions.

Références