Près du niveau de Claude Sonnet 5 avec le même corpus, pour une fraction du coût : ce que nous avons mesuré

Luca Paper utilise un modèle de langage existant. Nous lui ajoutons un corpus de textes publics officiels, versionné et découpé article par article et paragraphe par paragraphe, et une chaîne de rédaction en plusieurs étapes : recherche dans le corpus, lecture des paragraphes, plan, calcul, rédaction, contrôles automatiques. Un banc d'essai, séparé de la rédaction, juge chaque modification. Sur ce banc d'essai, notre chaîne de rédaction, avec un modèle peu coûteux, DeepSeek v4.1-flash, obtient 7,62/10 en moyenne sur quatre passages (de 7,17 à 7,83). Claude Sonnet 5, travaillant sur le même corpus avec notre méthode, obtient 7,83/10 sur un passage : au niveau de nos meilleurs passages, un peu au-dessus de notre moyenne (n = 6 par passage). Notre chaîne revient de 8,3 à 16,2 fois moins cher en coût d'API du modèle (de 0,66 $ à 1,29 $ pour les six notes selon le passage, aux prix facturés ces jours-là, contre au moins 10,71 $). Les deux configurations reposent sur le même corpus, dans son état au 1er octobre 2026, où chaque citation se vérifie à la source. La comparaison complète, avec la composition du corpus, est publiée dans L'IA peut-elle préparer une note fiscale ? Ce que nous avons mesuré.

Deux réserves comptent ici : le coût de Claude est une borne basse, et le rapport dépend du taux de cache de notre chaîne, mesuré sur la journée.

Nous modifions souvent l'outil, et chaque modification est mesurée : une consigne, une étape de rédaction ou une source ajoutée peut améliorer une note et en abîmer une autre, ce que quelques exemples ne suffisent pas à montrer.

Nos règles de mesure

• —
  Des cas figés. Un agent IA distinct écrit les cas : chaque cas est une demande de note sur un sujet comptable et fiscal français. Une fois écrit, le jeu de cas n'est jamais modifié pour faire passer une modification.
• —
  Ceux qui écrivent les consignes ne voient pas les cas. Les consignes données au modèle (les prompts) sont écrites sans voir ni les cas, ni les notes produites pendant les essais, ni leurs évaluations. Un test automatique échoue dès qu'une consigne partage une suite de quatre mots avec un cas ; on corrige alors la consigne, jamais le cas. Les consignes énoncent des principes, sans formules tirées d'un cas.
• —
  Un correcteur automatique séparé de la rédaction. Un modèle d'IA, Claude Opus, qui ne voit pas nos consignes et applique la même grille à toutes les notes. Il attribue un score sur 10, un verdict (à signer telle quelle, retouches légères, réécriture importante, inutilisable) et un relevé de défauts par type et par gravité. Il peut se tromper, et c'est arrivé (voir notre comparaison avec Claude).
• —
  Des règles de décision écrites, en principe, avant la mesure. On écrit d'abord ce qui fera garder ou annuler la modification, puis on mesure. Exception : la règle actuelle (11 octobre 2026) a été fixée après la mesure de la modification à laquelle elle s'est appliquée. Elle juge une modification contre l'étendue mesurée sur plusieurs essais de la version en place. Cette étendue vient de la version en place au 10 octobre 2026 : lancée trois fois sur les six mêmes cas de travail, un essai par cas, elle a obtenu un score moyen compris entre 7,17 et 7,83 (n = 6 par essai). Un seul essai ne suffit donc pas pour juger une modification.
• —
  Des notes jamais retouchées. Ce qui est évalué est exactement ce que l'outil a produit.
• —
  Des cas de travail et des cas de contrôle. Le jeu est coupé en deux moitiés. Six cas de travail servent à mesurer chaque modification de notre rédaction, et six cas de contrôle servent à vérifier qu'un gain ne vaut pas que pour les cas de travail (pas encore fait pour la version actuelle). Les six cas de travail sont ceux de la comparaison entre notre chaîne et Claude.

D'où nous partions : un même cas ne reçoit pas deux fois le même score

Notre première mesure date du 25 septembre 2026. Elle porte sur les 12 cas, trois essais chacun, soit 36 notes, pour un score moyen de 6,19/10 (n = 36). Ce chiffre ne se compare pas directement aux scores sur les six cas de travail. Le correcteur est exigeant : à ce point de départ, avant les modifications mesurées depuis, il n'a jugé qu'une seule de ces 36 notes à signer telle quelle.

La variabilité se voyait déjà. Le score d'un même cas variait en moyenne de 1,75 point entre le meilleur et le moins bon de ses trois essais (n = 12 cas).

Une modification peut atteindre son but et dégrader l'ensemble

Nous avons obligé l'outil à s'appuyer sur une fiche des faits tirée de la demande de l'auteur, à la rédaction comme à la vérification. Elle a atteint son but : sur les cas de contrôle, les notes qui remettaient en cause les faits fournis par l'auteur ont presque disparu. Mais elle a dégradé le reste. Nous l'avons mesurée sur les 12 cas, trois essais chacun, et comparée au point de départ.

• —
  Les notes devenaient plus irrégulières. Sur les cas de travail, l'écart moyen entre le meilleur et le moins bon essai d'un même cas est passé de 1,83 à 3,0 points. Le 1,83 est le point de départ restreint à ces six cas (1,75 sur les 12).
• —
  Sur les cas de contrôle, les notes comportant une erreur majeure sur la règle applicable ont doublé, de 4 à 8 notes (6 cas de contrôle × 3 essais).

La modification a été annulée : le gain sur un défaut ne compensait pas la dégradation d'ensemble.

Économie de la chaîne de rédaction

Voici les frais d'API du modèle pour chaque configuration, sur les six cas de travail.

¹ Au taux de cache de 86,39 % (voir « Jetons et coûts » et les limites). Sans cache : 5,41 $.

² Au taux de cache de 85,31 % mesuré sur la journée du 11 octobre 2026, aux prix facturés ce jour-là (voir « Jetons et coûts »).

³ Voir les limites (« Jetons de Claude + corpus »).

Toutes les lignes sont notées par la même version du correcteur. Nos deux passages sont ceux dont le coût a été mesuré ; sur ses quatre passages, notre chaîne obtient 7,62 en moyenne (de 7,17 à 7,83, voir notre comparaison avec Claude).

Les jetons, les prix relevés, le relevé d'activité OpenRouter de chaque journée et un script qui recalcule les chiffres de cette section sont dans le jeu de données du premier article. Deux exceptions : le script relit, sans pouvoir les refaire, les coûts des configurations de Claude en un seul appel, indiqués par Anthropic, et les jetons de Claude + corpus, tirés de journaux de session non publiés.

Jetons et coûts

Un jeton est l'unité de texte, de l'ordre d'un fragment de mot, que facturent les fournisseurs de modèles. Pour les six notes, notre chaîne de production a interrogé le modèle 322 fois. Elle lui a envoyé 20 303 957 jetons, et le modèle en a produit 564 137, soit 3 478 016 jetons par note, presque tous envoyés plutôt que produits.

Ce volume tient à ce que la chaîne travaille en boucle : elle cherche, lit un paragraphe, calcule, rédige. À chaque tour, elle renvoie au modèle tout le contexte accumulé (la demande, les textes déjà lus, le plan, le brouillon). Ce contexte grossit à chaque tour et repart en entier à chaque appel. L'essentiel du volume est donc de la relecture.

Le cache réduit fortement ce coût : le fournisseur facture beaucoup moins cher un texte qu'il a déjà reçu peu avant (« lecture de cache »). Prix de DeepSeek v4.1-flash chez le fournisseur Novita, par million de jetons, relevés sur OpenRouter le 2 octobre 2026 : 0,24 $ en entrée, 0,0048 $ en lecture de cache, 0,96 $ en sortie, soit les prix qu'OpenRouter nous a effectivement facturés.

• —
  Avec un taux de cache de 86,39 %, mesuré par OpenRouter sur la journée du 1er octobre 2026 (voir les limites), les six notes coûtent 1,29 $, soit 0,21 $ par note.
• —
  Sans aucun cache, le même travail coûterait 5,41 $.

Appliqués à toute la journée, nos prix et notre formule retrouvent la facture d'OpenRouter à 0,6 % près ; le détail figure dans les données téléchargeables.

Le passage du 11 octobre 2026 a interrogé le modèle 204 fois. Il lui a envoyé 12 549 131 jetons, et le modèle en a produit 326 886. Au taux de cache de 85,31 % mesuré ce jour-là et aux prix facturés ce jour-là, les six notes ont coûté 0,66 $ ; appliqués à toute la journée, ces prix retrouvent la facture d'OpenRouter (1,64 $).

Claude + corpus Luca Paper a consommé 38 813 591 jetons pour les six notes, soit environ 6,5 millions par note. Les prix de Claude Sonnet 5, relevés sur OpenRouter le 2 octobre 2026, sont de 2 $ en entrée, 0,20 $ en lecture de cache et 10 $ en sortie, par million de jetons. À ces prix, cela représente au moins 10,71 $, soit 8,3 fois le coût de notre passage du 1er octobre et 16,2 fois celui du passage du 11 octobre (voir les limites).

L'écart vient en partie du volume : Claude a traité près du double des jetons de notre passage du 1er octobre, et environ le triple de ceux du passage du 11 octobre. Il vient surtout des prix unitaires. Dans le coût calculé pour Claude, l'essentiel tient aux lectures de cache, facturées 0,20 $ par million de jetons contre 0,0048 $ chez DeepSeek. Dans notre chaîne, ces lectures ne pèsent qu'une faible part. Sa dépense va surtout à l'entrée hors cache et à la sortie, facturées 0,24 $ et 0,96 $ par million de jetons, contre 2 $ et 10 $ chez Claude.

Les configurations de Claude en un seul appel coûtent moins que notre chaîne : 0,69 $ pour les six notes avec internet, 0,37 $ sans outils (coûts indiqués par Anthropic). Mais ce sont elles qui obtiennent les scores les plus bas. Un appel unique ne va pas chercher les textes dans le corpus, alors que la dépense de notre chaîne va dans cette recherche. L'écart de qualité va dans le même sens que cette différence, mais nous ne pouvons pas l'y attribuer entièrement : notre premier correcteur, sans outils, avait sous-évalué une configuration sans corpus, et les scores ci-dessus viennent de sa version qui vérifie les citations dans le corpus (voir notre comparaison avec Claude).

Ces montants sont les coûts d'API du modèle pour ce banc d'essai, c'est-à-dire ce que facture le fournisseur du modèle. Ce ne sont pas les prix payés par un utilisateur de Luca Paper.

Méthode et limites

• —
  Petits échantillons. Six cas par moitié. Les essais de la même version (7,17 à 7,83 : trois pour notre règle de décision, quatre dans la comparaison avec Claude) et la comparaison des configurations portent sur les seuls six cas de travail, un essai par cas. Le point de départ et la modification sur la fiche des faits portent sur les 12 cas, trois essais chacun. Un ou deux cas suffisent à déplacer une moyenne.
• —
  Cas de travail. Ce sont ceux sur lesquels nous mesurons nos propres modifications. Notre chaîne et ses consignes ont donc été mises au point au vu de leurs scores. La configuration Claude + corpus suivait ces mêmes consignes et partage cet avantage ; les configurations de Claude sans corpus, non.
• —
  Un seul correcteur, Claude Opus, qui peut se tromper. Toutes les notes de la comparaison ont été notées par la même version, qui vérifie dans le corpus les citations des notes sans paragraphes joints.
• —
  Cas de contrôle. Les six cas de contrôle existent, mais ni la comparaison avec Claude ni la version actuelle de notre chaîne n'y ont encore été mesurées.
• —
  Configurations reconnaissables. Le correcteur peut distinguer les configurations : les notes rédigées avec le corpus lui arrivent avec les paragraphes cités joints.
• —
  Aucune notation humaine. Aucun expert-comptable n'a noté ces notes : les cas, la notation et la revérification sont automatisés.
• —
  Fiche des faits. Cette modification a été mesurée en même temps qu'un réglage antérieur, et nous ne pouvons pas séparer leurs effets.
• —
  Connecteur et consignes. La configuration Claude + corpus utilisait les outils publics de notre connecteur MCP, avec les consignes et les étapes de notre chaîne. Ces outils ne comprennent pas la recherche de comptes du plan comptable dont dispose notre chaîne. Nous n'avons pas mesuré le connecteur seul, sans ces consignes.
• —
  Choix des comptes. Nous travaillons sur le choix des comptes du PCG dans les écritures proposées ; en attendant, ce choix reste à vérifier par l'auteur.
• —
  Taux de cache sur la journée. Les 86,39 % portent sur tout notre trafic DeepSeek du 1er octobre 2026, dont le banc d'essai a fait 322 des 542 requêtes, et non sur le banc d'essai seul ; le coût sans cache est donné à côté. De même, les 85,31 % du 11 octobre portent sur toute la journée, dont le banc d'essai a fait 204 des 479 requêtes. Les rapports de 8,3 et 16,2 fois dépendent de ces taux et peuvent s'écarter dans un sens comme dans l'autre.
• —
  Prix. Ceux du passage du 1er octobre ont été relevés sur OpenRouter le 2 octobre 2026 ; ceux du passage du 11 octobre sont ceux qu'OpenRouter a facturés ce jour-là, retrouvés par la facture de la journée. Ils ont pu changer depuis.
• —
  Jetons de Claude + corpus. Ils ont été calculés à partir des journaux de session, chaque réponse comptée une fois. Ces journaux ne sont pas publiés. Les jetons produits qui y sont relevés paraissent incomplets. Le coût de cette configuration est donc une borne basse.
• —
  Chiffres recalculés. Les chiffres ont été recalculés à partir des fichiers bruts (données téléchargeables).
• —
  Données téléchargeables : les scores par cas anonymisé et les défauts par type, avec un script qui recalcule les chiffres de nos règles de décision. Les jetons et les coûts se recalculent avec le jeu de données du premier article, cité plus haut. Elles ne contiennent ni énoncé de cas, ni consigne, ni commentaire du correcteur. Les énoncés des cas et nos consignes sont disponibles sur demande, à hello@lucapaper.com.