Méthodologie : notre méthode de mesure

Ce que nous mesurons

Trois tâches courantes en entreprise : extraire 13 champs d'une facture (fournisseur, identifiants, numéro de document, référence de paiement, dates, HT et taxe par taux, total, devise, compte bancaire) ; trier les e-mails de clients (catégorie, priorité, tonalité, client, numéros de commande et de facture, montant, devise, échéance) ; et repérer les données personnelles dans des textes professionnels, par exemple avant de les envoyer à un service d'IA (noms, e-mails, téléphones, adresses, dates de naissance, numéros d'identification, comptes bancaires). Nous indiquons la part de champs corrects et la part de documents sans aucune erreur, car pour une entreprise ce second chiffre compte souvent davantage. Les documents sont en tchèque et en anglais américain.

Le jeu de test

Tous les documents sont synthétiques : générés à partir de données aléatoires mais valides (identifiants d'entreprise et numéros de naissance tchèques avec clé de contrôle, comptes bancaires selon les règles de la Banque nationale tchèque, EIN, numéros de routage ABA). La bonne réponse est donc la donnée source, pas une transcription manuelle, et elle ne contient pas de coquilles. Aucune donnée personnelle ou d'entreprise réelle : les e-mails utilisent des domaines .example, les numéros américains la plage fictive 555-01xx, les SSN une plage jamais attribuée. Un document tchèque et un document anglais forment une paire de même structure, ce qui permet de mesurer l'écart linguistique.

Les factures existent en huit mises en page avec des variantes réalistes (non assujetti à la TVA, facture d'acompte, avoir, devise étrangère) et à quatre niveaux : 30 % texte PDF, 30 % image nette, 30 % scan (rotation, bruit, JPEG), 10 % photo (perspective, ombre). Un tiers de chaque jeu n'est pas public ; nous n'en publions que des scores agrégés, pour qu'aucun modèle ne réussisse parce qu'il a déjà vu les réponses.

Les e-mails se présentent en message simple, avec une longue signature, en fil avec des messages antérieurs cités et en e-mail transféré par un collègue ; les échéances sont aussi relatives (« d'ici vendredi »). La priorité suit des règles fixes écrites dans le prompt ; ce n'est donc pas une question d'opinion. Les textes contenant des données personnelles (dossiers RH, tickets de support, comptes rendus, e-mails) comportent volontairement des données non personnelles : noms d'entreprise formés de noms de famille, identifiants d'entreprise, adresses génériques comme info@, numéros de commande et dates qui ne sont pas des dates de naissance.

Déroulement d'une exécution

Tous les modèles sont appelés via OpenRouter avec le même prompt dans la langue du document, à température 0, chaque modèle chez un fournisseur fixe pour que les résultats soient reproductibles. Si un modèle prend en charge la sortie structurée (schéma JSON), nous l'utilisons ; si le fournisseur refuse le schéma, nous relançons sans et le consignons. Si la réponse n'est pas un JSON valide, nous relançons une fois et le consignons aussi. Pour chaque appel, nous enregistrons le modèle, les versions du prompt et du jeu de données, les tokens, le coût, la latence et le fournisseur. Les sorties sont mises en cache : chaque semaine, nous ne payons que pour les nouveaux modèles, documents et prompts.

Notre notation

Un champ est correct lorsqu'il correspond exactement à la valeur attendue après normalisation du format : dates en AAAA-MM-JJ, montants en nombre à deux décimales (les deux conventions de séparateur), espaces ignorés dans les identifiants et numéros de compte. Les diacritiques ne sont pas normalisés : « Horak » au lieu de « Horák » est une erreur. Les erreurs sont classées par catégorie (champ manquant, valeur erronée, diacritiques perdus, dates inversées, HT au lieu du TTC, mauvais taux, format numérique, JSON invalide). Le seuil pour les factures est de 95 % de champs corrects.

E-mails : la catégorie, la priorité et la tonalité doivent correspondre exactement ; les échéances relatives doivent donner la bonne date. Données personnelles : chaque champ est une liste, correcte seulement si elle est complète et sans élément en trop ; un identifiant d'entreprise signalé comme donnée personnelle compte comme une valeur inventée. Le seuil est de 95 % de champs corrects pour toutes les tâches.

Coûts et taxe linguistique

Le coût correspond à la consommation réelle de tokens telle que renvoyée par l'API en USD, ramenée à 1 000 documents. La conversion vers d'autres devises n'intervient qu'à l'affichage, au taux indiqué en bas de page. La taxe linguistique est mesurée sur un corpus parallèle de 50 paragraphes en tchèque, allemand, français, espagnol, polonais et anglais : nous envoyons le texte avec une limite de sortie minimale, retranchons le surcoût d'un prompt vide et comparons les tokens d'entrée à ceux de l'anglais.

Le coût réel ajoute le travail d'une personne qui doit repérer et corriger chaque document erroné : 3 minutes par document à 450 CZK / 35 EUR / 40 USD de l'heure. La vitesse est le temps de réponse médian (90e centile dans l'info-bulle) ; les réponses valides sont la part de documents avec un JSON valide. Les erreurs de limitation de débit de l'API ne sont pas imputées au modèle : elles sont relancées jusqu'à ce que chaque document ait une réponse.

Le calculateur de coût réel utilise les coûts mesurés lorsque nous avons des documents dans la langue. Pour les autres langues, il estime : le surcoût mesuré sur de vrais documents dans une autre langue, ajusté par la taxe linguistique de la langue choisie (une image de facture coûte autant dans toutes les langues, le simple ratio de tokens surestimerait). Les estimations sont marquées ≈ et n'ont pas de précision.

L'écart linguistique

La différence de précision entre documents tchèques et anglais n'est calculée que sur les champs présents dans les deux versions. Les factures américaines n'ont ni numéro de TVA ni date du fait générateur : ces champs sont exclus de la comparaison.

Limites

Les documents synthétiques ne couvrent pas tout ce qu'une entreprise rencontre réellement (notes manuscrites, factures de plusieurs pages, mises en page inhabituelles). Avec environ 150 documents par langue, la précision comporte une incertitude d'environ ±1 point de pourcentage : ne considérez pas les écarts plus faibles entre modèles comme décisifs. Les modèles et les prix évoluent : chaque chiffre indique donc la date de l'exécution.

Indépendance

Les classements et les recommandations ne s'achètent pas. Aucun éditeur de modèle ne nous paie pour son positionnement. Si vous trouvez une erreur dans une bonne réponse ou dans la notation, signalez-la-nous : nous la corrigeons et documentons la modification.