Vous allez extraire les mêmes champs de quatre contrats, puis répondre à une question plus difficile : combien de fois le résultat était-il juste ? Pas « ça a l'air correct ». Un chiffre.
Huit parties. Les trois premières ressemblent à du travail ordinaire, et c'en est. Le reste, c'est ce qui transforme ce travail en quelque chose de fiable.
Vingt à trente pages chacun, rédigés comme l'est un vrai contrat fournisseur. Tous les secteurs en signent : juridique, comptabilité, services financiers, dommages corporels.
Un schéma est la définition formelle des données que vous voulez obtenir. Trois choses pour chaque champ.
« Valeur du contrat » paraît évident, jusqu'à ce que vous ouvriez le document et y trouviez trois chiffres qui peuvent tous y prétendre. Notez celui dont vous parlez.
Pointez Claude Code vers votre schéma et vers le contrat Northgate. Une ligne par champ, en suivant la colonne « règle de correspondance ».
Regardez le résultat. Quelque chose vous semble-t-il faux ?
Gardez-le en tête. Ne corrigez rien pour l'instant. Nous y reviendrons avec un chiffre plutôt qu'une opinion.
Transformez le prompt qui a marché en fichier, pour le relancer sans le retaper. Demandez à Claude Code de l'écrire, et de vous poser d'abord des questions de clarification.
Rien de malin. Si on l'enregistre maintenant, c'est que dans dix minutes vous allez vouloir lancer cette même extraction quatre fois, puis la relancer après l'avoir modifiée.
Lancez le skill sur les quatre. Une fiche par contrat, plus l'échéancier de charges complet pour chacun. Pas un échantillon. Tout.
Essayez de juger ça à l'œil. Donnez-moi votre taux d'erreur.
À la main, en vérifiant chaque valeur dans le document. Voilà le corrigé.
Demandez à Claude Code de comparer sa sortie au corrigé, champ par champ, et d'indiquer où ça correspond et où ça échoue.
Choisissez un des échecs et lisez-moi les deux valeurs à voix haute.
Une bonne réponse peut ne pas ressembler au corrigé. Retirez le formatage des deux côtés avant de comparer.
Normalisez le formatage des deux côtés avant de noter, sinon vous noterez la ponctuation au lieu des données.
Tout ce qui échoue encore après normalisation renvoie à un champ dont la règle de correspondance était vague, ou vide. Ouvrez le schéma que vous avez rempli il y a une heure.
Vous n'avez pas écrit une définition de données ce matin. Vous avez écrit le correcteur, puis vous avez écrit un outil qu'il corrige.
La spécification et le corrigé sont le même document.
Un mur de « réussi » et « échoué » est techniquement une évaluation et, en pratique, inutile. Vous voulez regarder ça et savoir en trois secondes quel champ pose problème.
Prenez le champ qui échoue le plus. Déterminez laquelle des trois causes c'est, changez la règle, et relancez le tout.
Corriger la réponse répare une cellule aujourd'hui et rien demain. Vous changez la règle et vous relancez. Si le score monte, c'était la règle le problème. S'il descend, vous avez appris quelque chose sur votre propre raisonnement.
Un score auquel vous faites trop confiance est pire que pas de score du tout. Cinq choses que cette session n'a pas enseignées, et que vous devez toutes connaître.
Ce que ça vous donne, c'est une direction. Changez une règle, et en une minute vous savez si ça a aidé ou nui. Ça suffit pour arrêter de deviner, et arrêter de deviner, c'est l'essentiel de la valeur.
Un corrigé note l'extraction, où une seule valeur est juste. Une grille note le jugement, où plusieurs résultats peuvent être bons. Entre les deux, vous mesurez les deux moitiés du travail. Aucun des deux ne mesure l'autre.
tutto.one/praxis · daniel@tutto.one