Livraison agentique : cahiers des charges, préséance et seuils d'évaluation

Pourquoi ce texte existe

La production d'un agent ne coûte rien. Savoir ce qui reste vrai une fois qu'il a fini, si. Mille lignes arrivent en une minute, et la question qui compte — laquelle de ces affirmations survit à la vérification — est justement celle que la vitesse rend facile à sauter. Ce qui suit est une tentative de rendre cette question vérifiable après coup, par un lecteur qui n'était pas là.

Cahier des charges et amendement

Le travail est parti d'un cahier des charges de base en sept sections, puis de deux amendements, de sept et six sections. Dix-huit commits, un par section. Les amendements ont été émis comme des documents, pas comme des corrections en chat : chacun nomme les sections qu'il supplante, et une section supplantée n'est ni supprimée ni réécrite — elle reste dans le registre, marquée comme telle.

Un troisième amendement a suivi le 2026-09-11, de sept sections, lorsque l'employeur a été nommé publiquement et que le site a dû s'aligner. Il supplante purement et simplement la règle d'anonymat de l'Amendement 2. C'est le premier amendement écrit après la publication du processus, ce qui en a fait un test de la règle plutôt qu'un simple usage : les tableaux de taux de réussite ci-dessous ont été mesurés avec des instruments que l'amendement invalidait, et la solution la moins coûteuse aurait été de les refaire discrètement. Ils n'ont pas été retouchés, et portent une note indiquant ce qui a changé en dessous.

La distinction compte parce qu'une correction en chat ne laisse aucune trace une fois la fenêtre de contexte renouvelée. Un document qui en supplante un autre laisse un registre où toute affirmation du site en ligne peut être retracée jusqu'à l'instruction qui l'a produite. La note en tête de la section de l'Amendement 1, verbatim :

spec-and-amendments.md — le registre section par section.

La préséance est la règle porteuse

Un exemple concret. L'Amendement 1 a livré un bandeau de crédits en page d'accueil affirmant un travail d'outillage "founding-engineer". L'Amendement 2 a corrigé le fait sous-jacent : troisième ingénieur recruté, premier Staff Engineer — énoncé sans détour plutôt qu'adouci, et corrigé aux quatre endroits où il apparaissait. La section de l'Amendement 1 n'a pas été réécrite pour autant. Elle reste dans le document, décrivant ce qui a été livré, avec la note ci-dessus en tête.

Sans cette règle, le registre de ce qu'on a demandé à l'agent dérive vers le registre de ce que le site affirme aujourd'hui, et les deux cessent d'être indépendants. Une fois qu'ils ne font plus qu'un seul document, aucune affirmation ne peut plus être retracée jusqu'à son instruction, et le registre ne peut plus contredire le site — ce qui est pourtant sa seule raison d'être.

L'inventaire des faits

Une section du cahier des charges n'était pas une instruction à rédiger quoi que ce soit. C'était une liste de faits vérifiés, et une règle permanente : ne rien affirmer qui ne soit couvert. Conséquence observable : une liste de dix-neuf points que l'agent a signalés plutôt que remplis. En voici deux :

• Invité à refléter un historique professionnel, l'agent a refusé de construire une chronologie datée. L'ordre de la source elle-même était ambigu — "Plus tôt : [employeur]" ne dit pas plus tôt que quoi — et il a demandé le véritable ordre plutôt que d'en deviner un.
• Face à un exemple d'historique de versions donné dans le cahier des charges lui-même (18 patterns, +6 nouveaux), il a constaté que les chiffres ne concordaient pas avec le total documenté de 28, et a dérivé 20 + 8 à partir des indicateurs isNew par pattern dans les données. Il a ensuite noté que ce n'était pas le nombre suggéré par le cahier des charges.

Six des dix-neuf points sont publiés ; treize sont retenus, avec le décompte et la raison de chaque catégorie indiqués. open-questions.md.

Boucles de vérification

Chaque section se terminait par une construction et un contrôle. Les contrôles qui ont trouvé quelque chose étaient les plus mécaniques : une construction (build) qui a prouvé qu'un défaut de rendu allégué n'existait pas, et des greps produisant des comptages avant/après pour des chaînes précises sur l'ensemble du dépôt plutôt qu'une inspection ponctuelle des fichiers que l'agent venait de modifier.

Le résultat le plus utile est venu d'un grep sur le langage de positionnement. Les règles de l'Amendement 1 lui-même interdisaient tout cadrage de recherche d'emploi dans le contenu des pages ; un grep en a trouvé deux larges sections déjà en ligne, préexistantes, dont un sous-titre lisant "Why I'm Seeking Senior ML Engineering Roles." Ni le cahier des charges ni l'amendement ne pointaient vers cette page. Le contrôle l'a trouvée parce que c'était un contrôle sur le dépôt entier, pas sur le seul diff.

Le défaut que le processus a trouvé en lui-même

L'Amendement 2 exigeait que l'employeur actuel ne soit nommé sur aucune surface publique. La section de vérification a consigné le contrôle sous forme de tableau, une ligne par chaîne cible. Une ligne couvrait le nom de l'employeur, sa maison mère, et un produit de marque associé, et affirmait zéro occurrence partout, y compris dans l'historique git.

Pour l'affirmer, la ligne épelait les trois chaînes en toutes lettres. Valider cette phrase les a écrites dans un fichier suivi et dans l'historique git. L'affirmation était fausse dès l'instant où elle a été consignée — non parce que le grep était erroné, mais parce que le fait de l'écrire invalidait le résultat qu'il rapportait. Le problème a été trouvé le 2026-09-01, deux jours après le commit, en relisant le document avant publication.

Aucune surface publiée n'a jamais été affectée : src/ et public/ étaient propres avant et après. Le document décrit désormais le contrôle sans nommer ses cibles, et l'affirmation sur l'historique est restreinte aux commits qui l'ont précédée. L'historique n'a pas été réécrit, et la correction le dit.

La règle sous laquelle ce défaut a été trouvé a depuis été retirée — l'Amendement 3 nomme l'employeur, parce qu'il a été nommé publiquement et que le site devait s'aligner. Le retrait de la règle a fait remonter une seconde occurrence du même défaut, dans un autre fichier : le commentaire source sur le filtre qui appliquait la règle au niveau du code affirmait lui aussi que les noms n'apparaissaient nulle part dans le dépôt, et son propre exemple de travail — un nom coupé en deux jetons streamés — était le vrai nom de la maison mère. Même forme, même fichier que l'affirmation, trouvé treize jours plus tard seulement parce que la règle était en cours de suppression. Une occurrence est une erreur ; deux sont la raison pour laquelle la règle ci-dessus est écrite comme une règle.

C'est la cinquième autocorrection du registre, et la seule portant sur le registre de vérification lui-même. Les quatre autres sont citées verbatim dans spec-and-amendments.md, dont une que l'agent a faite contre une affirmation qu'il avait lui-même posée plus tôt dans la même session.

Seuils d'évaluation

La fonctionnalité de chat sur la recherche du site était soumise à des seuils fixés avant tout résultat : 95 % d'exactitude des citations, 95 % de refus corrects, 90 % de réponses mentionnant leurs limites, et zéro tolérance sur chaque catégorie de red-teaming. Le jeu noté à l'époque comptait 50 éléments — 35 paires question/réponse dans le périmètre et 15 requêtes hors périmètre devant être refusées — plus 34 requêtes de red-teaming réparties sur cinq catégories d'attaque. Il compte depuis 56 éléments dans/hors périmètre ; les six ajoutés le 2026-09-08 ne sont pas encore notés. Le détail bug par bug de ce que ce seuil a intercepté figure sur la page du projet.

Deux des quatre seuils restent non atteints. L'exactitude des citations a terminé à 91,2 % contre un seuil de 95 %, et les réponses mentionnant leurs limites à 75,0 % contre 90 %. La fonctionnalité a été livrée avec ces chiffres consignés tels quels plutôt qu'avec les seuils abaissés pour les atteindre. Un échec de rappel en récupération a été laissé délibérément non corrigé : le changement qui l'aurait réglé dégradait d'autres éléments, et l'arbitrage est consigné plutôt que résolu.

La colonne du milieu est la raison de publier les six passes plutôt que les deux extrêmes. Le premier durcissement a amélioré le score global et rendu les refus parfaits, tandis que les réponses mentionnant leurs limites régressaient, de 66,7 % à 50,0 % — un coût réel qu'un simple résumé avant/après aurait masqué.

evals/README.md · jeu de référence · taxonomie du red-teaming · passe de référence · passe finale. Les fichiers de résultats portent chaque réponse modèle, élément par élément, ce qui en fait un reçu plutôt qu'un résumé.

Limites

Il s'agit d'un n = 1. Un site, un agent, dix-huit commits, aucune condition témoin. Rien ici n'établit que la structure de cahier des charges et d'amendements a causé le résultat plutôt qu'elle ne l'a simplement accompagné, et aucune comparaison n'a été menée contre le même travail effectué sans elle.

Le juge d'évaluation est lui-même un modèle, et les seuils ont été fixés par la même personne qui note par rapport à eux. Un site personnel est aussi le cas facile : les coûts de coordination qui dominent une livraison réelle — plusieurs personnes modifiant le même cahier des charges, un désaccord sur ce qu'est un fait, une pression de délai contre un seuil non atteint — sont absents par construction. La règle selon laquelle un registre de vérification ne doit pas nommer ce qu'il certifie absent est une règle générale. La preuve que le processus environnant passe à l'échelle n'est pas ici.

Deux des quatre documents publiés sont des extraits caviardés, pas des sources complètes. Chacun indique ce qui a été retiré et par catégorie, et les décomptes retenus sont énoncés plutôt qu'omis — mais un lecteur fait confiance au fait que le caviardage n'a retiré que ce qu'il dit avoir retiré.

Artefacts

• /process/README.md — index et politique de caviardage
• spec-and-amendments.md — le cahier des charges, les deux amendements, la règle de préséance, chaque autocorrection (extrait caviardé)
• open-questions.md — six des dix-neuf points signalés, et les catégories des treize retenus (extrait caviardé)
• evals/ — jeu de référence, taxonomie du red-teaming, et six passes datées avec les réponses détaillées par élément (copies intégrales)
• evals/harness/ — le code qui a produit ces passes : golden_harness.py, redteam_harness.py, et les quatre modules qu'ils importent. Publié pour que les chiffres puissent être régénérés plutôt que pris pour acquis (copies intégrales)

Les fichiers d'évaluation sont copiés à l'identique depuis l'espace de travail source à chaque build, et la CI échoue si une copie est obsolète. Les deux extraits sont rédigés à la main, parce que le caviardage est un jugement qu'aucun script ne peut faire ; ils échappent à cette garantie et portent une date de relecture à la place. Le dépôt source est privé.