Idée principale

L'article qui décrit le moteur de contexte porté sur ChatGPT a été préparé dans ce moteur : idées persistées, sources ingérées, angles morts identifiés, tâches créées puis terminées, première version produite, relue, puis reprise en V2 depuis le même contexte. Le système n'a pas été testé par un scénario construit pour lui ; il a été chargé de faire le travail pour lequel il existait.

La différence n'est pas de rigueur mais de nature de l'épreuve. Une démonstration choisit ses données et son parcours — elle vérifie que le chemin prévu fonctionne. Un travail réel amène ce que personne n'avait prévu : une idée qui arrive dans le désordre, une contradiction entre deux notes, une reprise plusieurs jours après, un volume qui n'était pas anticipé. Ce sont ces situations-là qui décident si un système tient.

Pourquoi c'est important

Cela change ce qu'on peut affirmer à la fin. Après une démonstration, on sait que le système fait ce qu'on lui a demandé de montrer. Après un travail réel mené jusqu'au livrable, la question « est-ce que ça fonctionne » est close, et la question suivante devient celle de la montée en charge — ce qui est un progrès, parce qu'elle porte sur un usage et non sur une capacité.

Et cela fournit une discipline pratique : choisir comme premier usage d'un système celui qu'on doit de toute façon produire, plutôt qu'un cas d'école qui ne coûte rien d'abandonner.

Nuances et limites

Un seul travail réel n'épuise pas les régimes d'usage. Produire un article sur quelques jours ne dit rien du comportement d'un contexte alimenté pendant plusieurs semaines, ni d'une semaine de terrain dense — et l'article le reconnaît explicitement.

Et l'épreuve est biaisée par son opérateur : celui qui a construit le système contourne sans y penser ce qu'il sait fragile. Le travail est réel, l'utilisateur ne l'est pas tout à fait.

Questions ouvertes

• Comment distinguer, dans un système éprouvé par son auteur, ce qui tient du système et ce qui tient des contournements qu'il fait sans les voir ?