Idée principale

Représenter un contexte dans Google Drive laissait deux options : un Google Doc par type d'information — les sources, l'état, les connaissances, les tâches — ou un seul Spreadsheet avec un onglet par type. Les deux structures sont équivalentes du point de vue de l'information ; elles ne le sont pas du point de vue de l'accès. La première oblige l'assistant à retrouver et à tenir autant d'identifiants Google qu'il y a de documents, la seconde un seul, celui du Spreadsheet, à l'intérieur duquel les onglets se nomment sans coût.

Le critère décisif n'était donc ni la lisibilité, ni l'élégance du découpage : c'était combien d'objets il faut savoir localiser avant de pouvoir lire ou écrire quoi que ce soit. Un Contexte est devenu un Spreadsheet, et chaque type d'information un onglet.

Pourquoi c'est important

Cela introduit un critère qu'on oublie quand on conçoit une arborescence à la main : un humain retrouve ses fichiers par navigation visuelle et ne paie presque rien pour leur nombre ; un agent les retrouve par résolution d'identifiant, et paie chaque objet en appels et en latence. Une structure confortable à l'écran peut être hostile à la machine qui doit y écrire.

Le choix du support devient alors un arbitrage à deux termes — la forme de l'information et le coût de son adressage — au lieu d'un seul.

Nuances et limites

Le regroupement a ses propres limites : un Spreadsheet unique concentre les risques de contention, plafonne en volume, et rend toute permission plus grossière — on partage le contexte entier ou rien, là où des documents séparés se partageraient un par un.

Et le critère faiblit dès que la résolution d'identifiant devient bon marché : mise en cache ou index tenu à jour, la multiplicité des documents cesse d'être coûteuse, et l'arbitrage revient à la forme de l'information.

Questions ouvertes

• À partir de quel volume un contexte tenu dans un seul Spreadsheet doit-il être scindé, et sur quel signal plutôt que sur quelle limite affichée ?