Idée principale

Un skill doit analyser trois fiches clients. Faute de filtre à l'entrée, il en charge cinq cents. Le résultat produit est identique ; la dépense, non — environ 150 000 tokens d'entrée pour de la matière qui ne servira jamais.

Le coût d'une lecture ne suit pas ce qu'on en tire, il suit ce qu'on a mis dans la fenêtre. Un agent ne « survole » pas : tout ce qui entre est payé, y compris ce qu'il écarte immédiatement.

D'où un déplacement du travail d'optimisation : la question n'est plus comment mieux demander, mais comment interroger la base — filtre, pagination, sélection préalable par script. La lecture conditionnelle va plus loin encore : ne pas ouvrir du tout une source quand une condition préalable n'est pas remplie.

Pourquoi c'est important

Cela situe l'économie du côté de l'accès aux données plutôt que du côté du prompt, là où on la cherche d'ordinaire.

Et cela donne un symptôme repérable dans un rapport d'audit : une étape de lecture dont le volume est sans rapport avec le nombre d'éléments réellement traités.

Nuances et limites

Filtrer suppose de savoir d'avance ce qui est pertinent. Quand la pertinence est précisément ce que l'exécution doit établir, la lecture large n'est pas un gaspillage, c'est le travail.

Et une sélection mal posée est pire qu'une lecture complète : elle produit une réponse plausible sur une matière tronquée, sans que rien ne le signale.

Questions ouvertes

• Comment mesurer, après coup, la part des données chargées qui a réellement pesé sur la sortie ?