Méthodologie
Deux parties : la méthode commune à tout le hub, puis le protocole propre à chaque benchmark mesuré. Tout est vérifiable dans le dépôt — le prompt envoyé, le barème appliqué, les documents soumis et les réponses brutes de chaque modèle.
L'indice métier
L'indice métier résume un modèle en un chiffre. Il se calcule en deux temps :
- le score d'un métier est la moyenne de l'exactitude du modèle sur les benchmarks de ce métier qu'il a passés, arrondie au dixième de point ;
- l'indice est la moyenne de ces scores par métier, arrondie de la même façon.
Chaque métier pèse donc autant que les autres, quel que soit son nombre de benchmarks : un métier doté de trois tests ne compte pas trois fois. Un modèle qui obtient 90 % et 70 % sur les deux benchmarks d'un métier, et 50 % sur l'unique benchmark d'un autre, a pour scores 80 % et 50 %. Son indice est 65 %, et non 70 %, la moyenne des trois tests.
L'indice ne porte que sur les métiers déjà mesurés. Un métier dont aucun benchmark n'a encore été joué n'entre pas dans le calcul : il ne compte pas comme un zéro, il ne compte pas du tout. Combien de métiers l'indice couvre est écrit à côté de lui, parce qu'un indice sur un métier ne vaut pas un indice sur dix.
En revanche, un modèle absent d'un métier que les autres ont passé n'a ni indice ni rang : il figure comme « Non classé », à la fin des tableaux. Son indice ne se comparerait à aucun autre.
Un modèle qui ne lit pas les documents — ni image ni PDF — ne passe pas les benchmarks qui en soumettent. Dans chaque métier, il est noté sur les seuls benchmarks texte ; un métier qui n'en compterait aucun le priverait d'indice. Son indice repose donc sur moins de tests que celui des autres : le nombre de benchmarks passés est affiché à côté.
L'indice n'agrège que l'exactitude. Le coût, le temps et le taux d'hallucinations d'un modèle sont des moyennes sur les benchmarks qu'il a passés, affichées à part et jamais fondues dans l'indice. Un tarif inconnu n'entre pas dans la moyenne des coûts.
Le rang suit l'indice, du plus élevé au plus bas. Sur un benchmark, il suit l'exactitude.
La marge d'erreur
Un score mesuré sur quelques dizaines de documents n'est pas connu au dixième de point près. La marge d'erreur le dit : c'est la demi-largeur de l'intervalle de confiance à 95 % sur l'exactitude, en points. Quand un classement la publie, elle s'affiche à côté du score : « ± 2,1 ».
Deux modèles séparés par moins que la plus grande de leurs deux marges ne sont pas départagés. Le tableau les range quand même, parce qu'il faut bien un ordre ; la page du benchmark écrit, elle, que le test ne les départage pas. Sans marge publiée, le site ne déclare aucun ex æquo.
L'indice métier a sa propre marge, combinée à partir de celles des benchmarks passés : la racine de la somme de leurs carrés, divisée par leur nombre. Elle n'est publiée que si chaque benchmark passé par le modèle publie la sienne.
La marge décrit le hasard du tirage des documents. Elle ne dit rien des limites du protocole, listées plus bas.
Coûts et tarifs
Les tarifs affichés sont les tarifs publics des modèles, en dollars par million de tokens, en entrée et en sortie. Ils sont synchronisés depuis le catalogue public d'OpenRouter — la passerelle par laquelle les appels sont réellement facturés — comme les fenêtres de contexte ; dernière synchronisation le 2 octobre 2026.
Ils restent en dollars : les convertir daterait le chiffre. Un modèle absent du catalogue porte la mention « Non communiqué » plutôt qu'un prix recopié de mémoire.
Le coût par test est la moyenne des appels réussis, au tarif du jour du test : les tokens consommés par chaque appel, multipliés par le tarif du catalogue. Il est relevé à l'exécution, jamais reconstitué après coup, et recalculé depuis les tarifs publiés plutôt que lu chez le fournisseur : un lecteur du dépôt peut refaire la multiplication.
Un appel en échec n'entre dans aucune moyenne, et il est compté à part. Un modèle qui échoue sur plus d'un dixième du jeu bloque la publication du classement.
Un échec peut malgré tout avoir été facturé : un modèle qui répond puis dépasse la limite de longueur consomme des tokens sans rendre de résultat exploitable. Ces appels sont enregistrés avec leur coût, pour que le total dépensé soit exact, mais ils ne pèsent pas sur le coût par test d'un modèle.
Les échecs ne pénalisent pas la note d'un modèle. Dans ce projet, ceux qu'on a observés venaient du quota du compte, du crédit réservé par les appels simultanés ou d'un hébergeur en panne — de notre côté, donc. Leur nombre reste affiché dans le classement : un modèle qui échouerait pour une raison qui lui est propre doit se voir.
Le temps affiché est une médiane, pas une moyenne : un seul appel lent fausserait la moyenne.
Comment une réponse est vérifiée
Interroger un modèle est la partie facile. Tout le reste tient dans une question : comment sait-on que sa réponse est bonne ?
Aucune IA n'évalue une IA. La référence est écrite par des humains, avant le test et sans connaître les modèles qui y passeront. Pour les factures, ce sont des journalistes qui ont saisi chaque champ à la main. Faire juger un modèle par un autre modèle reviendrait à mesurer leur accord, pas leur justesse.
La comparaison est faite par un programme écrit à la main, champ par champ, selon la nature de l'information :
- un montant est ramené à un nombre, puis comparé au centime près ;
- une date est ramenée à l'année-mois-jour depuis la dizaine de formes que les modèles emploient — « 12/03/2020 », « March 12, 2020 », « 2020-03-12 » — en appliquant la convention de lecture du pays du document, et non celle du lecteur ;
- un identifiant ou un nom est comparé après normalisation : accents, espaces, ponctuation, abréviations courantes ;
- une liste de lignes est appariée ligne à ligne, l'ordre ne comptant pas.
Ce programme ne devine jamais. Quand il ne sait pas trancher — une valeur illisible dans la référence, une forme qu'il ne reconnaît pas — la réponse part en relecture humaine plutôt que d'être comptée comme fausse. Une référence qu'on ne sait pas lire fait échouer la préparation du test : sans cette règle, elle deviendrait un « rien » silencieux, et un modèle qui a correctement lu le document serait accusé d'avoir inventé.
Le même document, le même prompt, les mêmes conditions pour tous les modèles. Un document que l'un des fournisseurs refuse — trop de pages, trop de pixels — est retiré du test pour tout le monde, pas seulement pour lui : un classement doit comparer des modèles, pas des sous-ensembles de documents.
Les questions ambiguës sont écartées, pas corrigées après coup. Si un champ admet plusieurs réponses défendables, le noter mesure si le modèle devine ce que nous voulions, pas s'il sait lire. Le champ est alors retiré du barème et la raison est écrite dans le barème lui-même ; les réponses des modèles restent publiées.
Enfin, les quatre étapes du pipeline sont séparées et immuables : appeler les modèles, noter, arbitrer, publier. Les réponses brutes sont écrites une fois pour toutes, et renoter ne coûte pas un appel. C'est ce qui permet de corriger un barème sans jamais retoucher une réponse.
Les réponses brutes des 27 modèles interrogés sont dans le dépôt, un dossier par modèle : n'importe qui peut refaire la notation et retrouver les chiffres publiés.
Rien de ce que le site affiche n'est fabriqué. Une tâche est mesurée et porte ses chiffres, ou elle est au programme et n'en porte aucun.
À ce jour, aucun classement publié n'est une démonstration : tous les chiffres du site viennent d'appels réellement passés.
Mesuré ou à venir
Chaque benchmark porte l'une de ces deux mentions :
- Protocole exécutable : la tâche se joue de bout en bout et porte des chiffres mesurés. Sa définition, son barème, son prompt, ses documents et leurs annotations sont dans le dépôt ; n'importe qui peut relancer le pipeline et retrouver les chiffres.
- À venir : le protocole est rédigé — la question posée, ce que reçoit le modèle, les sous-tâches, la taille d'échantillon visée — mais le jeu de test reste à construire. Aucun chiffre n'est affiché.
Mesurés à ce jour : 1 sur 22 (Lecture de factures publicitaires).
Une tâche à venir dit ce qui lui manque, parce que les causes ne s'équivalent pas : un jeu public réel et annoté qu'il reste à intégrer ; une tâche dont aucune référence publique ne donne la bonne réponse, et qui demande donc une grille de notation et un arbitrage humain ; ou des documents qui ne sortent jamais des entreprises, et qu'il faudra collecter auprès de partenaires avec leur accord.
Pourquoi publier un protocole avant ses résultats ? Parce qu'il ne pourra plus être retouché ensuite pour arranger un classement, et parce qu'il se discute mieux avant qu'après.
Protocole d'un benchmark
Le protocole : Lecture de factures publicitaires
Tout ce qui précède vaut pour l'ensemble du hub : l'indice métier, la marge d'erreur, l'origine des coûts, la maturité d'une tâche. Ce qui suit ne vaut que pour un seul benchmark. Ses limites, son barème, ses verdicts, son prompt et son dernier run lui appartiennent, et ne disent rien des autres.
Chaque benchmark aura ici sa propre section, à mesure qu'il sera mesuré. Un protocole ne se transpose pas d'une tâche à l'autre : un montant se vérifie au centime, alors que trier des candidatures ou résumer un contrat demande une tout autre grille — et des jugements qu'aucun comparateur automatique ne rend.
Lecture de factures publicitaires
Ce que ce test ne mesure pas
- Un seul prompt par modèle. Un prompt travaillé pour un modèle donné améliorerait ses résultats ; nous mesurons ce que donne une intégration standard.
- Aucun ajustement fin, aucun OCR spécialisé en amont. Une chaîne de traitement dédiée ferait mieux.
- Cent documents, pas dix mille. Assez pour voir un écart de vingt points, pas pour départager deux modèles séparés d'un point. La marge d'erreur de chaque score le dit.
- Des factures américaines, en anglais, et d'un seul secteur : l'achat d'espace publicitaire télévisé. Rien ne garantit que ces résultats se transposent à une facture française.
- Des images, pas des PDF avec couche texte. Un PDF natif est plus facile à lire pour un modèle : les scores publiés sont un plancher, pas un plafond.
- Deux champs notés. Les autres champs de ces factures admettent plusieurs réponses défendables — six identifiants concurrents, deux périodes distinctes — et la question ne leur est plus posée.
- Pas de lignes de facturation. C'est la vraie difficulté du métier, et l'annotation d'origine ne la couvre pas : il faudrait construire notre propre référence.
- Une tâche plus facile que prévu. Vingt-cinq modèles sur vingt-sept dépassent 97 % : ce test les sépare mal, et il faut le lire comme un seuil d'entrée plutôt que comme un palmarès.
Lecture de factures publicitaires
Le barème
Les champs sont pesés par ce qu'une erreur coûte en comptabilité, pas par leur difficulté technique. Un champ critique faux fait basculer toute la facture en « à relire ».
| Champ | Comparaison | Poids | Critique |
|---|---|---|---|
| Montant total facturé | au centime | 3 | oui |
| Numéro de TVA | identité, ponctuation ignorée | 1 | non |
Un champ vaut son poids ou zéro, sans demi-point. L'exactitude est la somme des points obtenus rapportée au total possible. Une facture passe « sans relecture » quand aucun de ses champs critiques n'est faux, manquant ou inventé ; une facture que le modèle n'a pas réussi à traiter ne passe pas.
La comparaison est tatillonne là où le métier l'est : les montants se comparent au centime. Elle est indulgente là où il l'est aussi : un identifiant s'écrit avec ou sans espaces, et l'ordre des lignes de facturation ne compte pas.
Les dates suivent la convention du pays du document, déclarée champ par champ dans le barème. Sur ces factures américaines, 03/04/2020 est lu comme le 4 mars ; sur une facture française, la même écriture désignerait le 3 avril. Lire une date américaine à la française avait d'ailleurs produit, sur un premier essai, une vingtaine d'erreurs attribuées à tort aux modèles.
Lecture de factures publicitaires
Les trois verdicts
Un champ absent du document fait partie du test. Répondre « rien » quand il n'y a rien est compté comme une bonne réponse ; produire une valeur l'est comme une hallucination, comptée à part du reste et jamais fondue dans une note globale.
- Juste : la valeur du document, ou « rien » quand le document ne contient rien.
- Faux ou manquant : une autre valeur que celle du document, ou rien alors que l'information y figurait.
- Halluciné : une valeur là où le document n'en contient aucune.
Seul un champ juste rapporte des points. L'hallucination alimente en plus sa propre mesure : la part des champs réellement absents que le modèle a quand même remplis. Un modèle qui écrit « non trouvé » ou « n/a » s'abstient correctement : sa réponse est ramenée à « rien » avant d'être notée.
Le code n'a pas le dernier mot. Une étape d'arbitrage humain sélectionne les réponses à relire — toutes les hallucinations, celles jugées justes mais écrites autrement que la référence, et un échantillon des autres — et le verdict de l'humain remplace celui du code dans le calcul.
Sur le run publié, cette étape n'a pas encore été jouée : les chiffres affichés sont ceux du comparateur seul. 80 notations sur 2700 sont marquées « à relire », et le classement le dira autrement quand elles auront été arbitrées. Le dire plutôt que de laisser croire à une relecture qui n'a pas eu lieu fait partie du protocole.
Lecture de factures publicitaires
Le prompt, intégralement
Envoyé tel quel à chaque modèle, avec les pages scannées de la facture. Le même pour les vingt-sept, sans un mot de différence.
You are given the pages of a broadcast advertising invoice, as images.
Extract the requested information and answer with a JSON object only.
## The most important rule
If a piece of information **does not appear** on the document, answer `null` for
that field. Never guess, never infer, never fill in what looks usual. A value you
invent is treated as a serious error — worse than admitting you did not find it.
## Fields
- `contract_num` — the contract or order number identifying this buy, exactly as
printed. String.
- `advertiser` — the value of the field labelled `Advertiser` or `Advertiser Name`:
the client who bought the advertising. Not the TV station, not the media agency,
and not the `Product` or `Brand` field, which often repeats the advertiser's name
in a different form. String.
- `gross_amount` — the total gross amount invoiced, for the whole document.
This is usually a grand total, and it is often on a later page than the first.
Number.
- `flight_from` — the first day of the advertising period covered by this invoice.
When the document names that period — a field labelled `Flight Dates`,
`Order Flight` or `Flight` — use it, and prefer it over `Invoice Period`,
`Bill Period` or `Bill Plan`, which cover the billing cycle and often start on a
different day. **Many of these documents have no flight field at all**: they
carry only a billing period, usually labelled `Period`. Use that one then, and
do not answer `null` — the period is on the document, under another name.
Format `YYYY-MM-DD`. String.
- `flight_to` — the last day of that flight. Format `YYYY-MM-DD`. String.
- `vat_number` — the VAT registration number of the issuing company, if the
document carries one. String.
## Value formats
- Dates: `YYYY-MM-DD`. A date printed `02/03/20` on a US document means
3 February 2020, so it becomes `2020-02-03`.
- Amounts: a plain decimal number, **no currency symbol and no thousands
separator**. `$1,880.00` becomes `1880.00`.
## Output
A JSON object with exactly these six keys, and nothing around it.
Lecture de factures publicitaires
Ce test
| Run | 2026-09-27_facture-fcc+2026-10-02_facture-fcc+2026-10-04_facture-fcc+2026-10-05_facture-fcc |
|---|---|
| Date | 5 octobre 2026 |
| Documents | 100 |
| Modèles | 27 |
| Statut | mesure réelle |