Ajustement fin ou appel à l’API ? Évaluation des coûts d’un processus d’extraction de documents

Les dirigeants du domaine de l’ingénierie se posent constamment la même question, généralement juste après l’arrivée de la première facture importante d’OpenAI ou d’Anthropic : le groupe doit-il affiner son propre modèle ou continuer à utiliser l’API ? La réponse attendue est que l’affinage est moins coûteux. Cela peut être vrai parfois, mais généralement pour des raisons plus limitées que ce que l’on imagine, et pour de nombreux groupes, c’est tout simplement faux. Cet article analyse un système réel à forte composante documentaire, évalué des deux manières, en utilisant les prix indicatifs de septembre 2026, afin que vous puissiez voir d’où proviennent réellement les économies, quand il est justifié de posséder un modèle, et comment prendre cette décision sans risquer huit semaines de travail d’ingénieur sur une simple supposition.

L’option que l’on imagine n’existe plus

Un changement a discrètement redéfini tout le débat : au moment de la rédaction de cet article, il n’est plus possible d’affiner un modèle de pointe actuel.

D’après la page des tarifs d’OpenAI, sa plateforme de fine-tuning est progressivement supprimée : les nouveaux clients ne peuvent pas s’inscrire, et o4-mini est le seul modèle encore pouvant être affiné, facturé 100 dollars par heure d’entraînement. L’API d’Anthropic n’a jamais offert de fonctionnalité de fine-tuning. La seule méthode utilisée par le passé était le fine-tuning supervisé de Claude 3 Haiku sur Amazon Bedrock, et Haiku 3 a depuis été retiré de tous les autres supports à l’exception de Bedrock et Google Cloud.

Ainsi, à la fin de 2026, l’expression « fine-tuning versus frontier » désigne en réalité quelque chose de plus précis : prendre un modèle à poids ouvert comme Qwen, Llama, une variante de Nemotron ou gpt-oss, entraîner un adaptateur LoRA à partir de ses propres données, puis le héberger sur sa propre infrastructure ou auprès d’un fournisseur comme Fireworks ou Together. Les risques liés à ce choix ne sont pas ceux que l’on imagine habituellement, concernant plutôt le choix du modèle, son évaluation et sa mise en service, tâches que gère normalement pour vous une API hébergée. Il convient d’être précis à ce sujet avant de le présenter au conseil d’administration.

Le système de référence : une plateforme de preuves d’audit

Le système présenté ici n’est pas un outil simplifié. Il s’agit d’une plateforme complète de preuves d’audit destinée à une entreprise de taille moyenne, du type de produit que pourrait réellement acquérir un cabinet comptable britannique ou nordique. Il fonctionne en sept étapes :

1. Reception des données. Les clients téléchargent des fichiers via un portail, généralement sous forme de PDF scannés. Les documents typiques sont les factures, les bons de commande, les notes de réception de marchandises, les relevés bancaires, les baux et les procès-verbaux des réunions du conseil d’administration.
2. Classification. Chaque document est classé dans une catégorie spécifique et envoyé à la vérification appropriée.
3. Extraction des informations. Les champs structurés sont extraits selon un schéma prédéfini, incluant le fournisseur, la date, le montant net, la TVA, la référence du bon de commande, la personne chargée de l’approbation, la monnaie et le centre de coûts. Le résultat doit être un JSON valide qui respecte strictement ce schéma à chaque fois.
4. Vérification de contrôle. Cette étape vérifie si la facture correspond bien au bon de commande et à la note de réception, ainsi que si la personne ayant approuvé le document disposait des autorisations nécessaires. La majeure partie de cette fonctionnalité repose sur du code ordinaire plutôt que sur un modèle.

Exception triage. Tout élément qui échoue à un test est noté et classé.

Rédaction du rapport de travail. Le système rédige une première version de chaque constatation, par exemple indiquant que 42 paiements dépassant le seuil de 50 000 livres sterling ont été testés et que trois d’entre eux ne disposaient pas d’une approbation secondaire documentée.

Questions-réponses avec les auditeurs. Les auditeurs consultent l’ensemble du dossier de mission et reçoivent des réponses fondées, accompagnées de références aux documents sources.

Les étapes 2 et 3 consomment presque tous les tokens, et ce sont également les parties les plus répétitives, mécaniques et soumises à des contraintes de schéma du système. Les étapes 6 et 7 sont celles où le jugement réel a lieu, mais leur part du volume est négligeable. Gardez cette répartition à l’esprit, car le reste de l’analyse en dépend.

Estimation du volume des tokens

Le modèle suppose que chaque document est d’abord converti en texte à l’aide de la reconnaissance optique de caractères avant d’être traité par le modèle. Cela permet d’éviter un tarif basé sur les tokens d’image, ce qui est de toute façon la pratique habituelle.

Chaque document passe par trois étapes (classification, extraction et vérification automatique), ce qui représente en moyenne :

• 5 200 tokens d’entrée, couvrant le texte du document, le schéma ainsi que quelques exemples.
• 600 tokens de sortie pour le résultat structuré.

Deux niveaux de volume sont pris en compte :

• Pilote : 100 000 documents par mois, correspondant à une entreprise pendant une période de forte activité.
• Échelle : 2 000 000 de documents par mois, correspondant au même produit vendu à cinquante entreprises.

Cela correspond à environ 580 millions de tokens par mois pour le niveau pilote et 11,6 milliards pour le niveau échelle.

À quoi ressemble la facture

Les chiffres ci-dessous utilisent les prix de liste standard avec un routage mondial, sans remises pour des commandes groupées ou du cache, tels qu’affichés sur la page de tarifs de chaque fournisseur en septembre 2026. Les prix changent fréquemment, il convient donc de les considérer comme une donnée à titre indicatif et de les vérifier à nouveau avant d’établir un budget.

Au niveau de volume pilote, le besoin d’un affinage disparaît. Exécuter l’ensemble du pipeline d’extraction sur Claude Sonnet 5 coûte environ 1 640 $ par mois, Haiku 4.5 environ 820 $, et un modèle 8B affiné environ 116 $. Économiser environ 1 500 $ par mois ne compense jamais les efforts nécessaires pour créer un modèle affiné. À ce stade, il est préférable d’utiliser l’API.

Au niveau de volume élevé, le choix devient réellement important :

• Claude Opus 5 : environ 82 000 $ par mois
• GPT-5.6 Sol : environ 65 600 $ par mois
• Claude Sonnet 5 : environ 32 800 $ par mois
• Claude Haiku 4.5 : environ 16 400 $ par mois
• GPT-5.6 Luna : environ 3 520 $ par mois

8B affiné, hébergé sans serveur : environ 2 320 $ par mois

Il est tentant de mettre en avant une économie de plus de 90 % grâce à l’affinage, et les calculs le confirment par rapport aux versions phares : le coût d’affinage représente environ 7 % du tarif de Sonnet 5 et moins de 3 % de celui d’Opus 5. Cependant, aucune équipe ne devrait procéder à l’extraction massive d’factures à partir d’un modèle phare. Comparer un design optimisé à un design délibérément gaspilleur relève du marketing, et non de l’analyse.

C’est le routage, et non l’affinage, qui permet les grandes économies

Comparez les deux dernières lignes de cette liste : 3 520 $ pour GPT-5.6 Luna contre 2 320 $ pour le modèle 8B affiné. La différence s’élève à 1 200 $ par mois, soit environ 14 400 $ par an.

La mise en place correcte du fine-tuning implique l’étiquetage des données, la création d’un outil d’évaluation, l’exécution de l’entraînement, la mise en place d’un système de déploiement et l’ajout d’une surveillance des dérives. Une estimation raisonnable est de huit semaines-homme d’ingénieur. En multipliant ce chiffre par le tarif typique d’un prestataire européen, le retour sur investissement uniquement grâce aux économies réalisées dépasse largement dix-huit mois, même avec les tarifs les plus élevés.

La conclusion la plus utile est que la plus grande réduction de coûts provient du routage. En déplaçant les tâches de classification et d’extraction du service principal vers le niveau le moins cher qui satisfait encore vos critères d’évaluation, les frais liés à Opus passent de 82 000 $ à 3 520 $ par mois, soit une réduction d’environ 96 %. Avec un routeur et un ensemble d’évaluation fiable, ce changement peut être réalisé en une après-midi. Un affinage supplémentaire permet d’économiser encore environ 34 %. Le même principe, qui consiste à adapter la taille du modèle à chaque appel, est abordé plus en détail dans right-sizing LLMs with routing, retrieval and evaluation.

La formation elle-même est presque gratuite. Fireworks propose un affinage supervisé LoRA pour des modèles allant jusqu’à 16 milliards de paramètres au prix de 0,50 dollar par million de tokens d’entraînement. Vingt mille exemples étiquetés de 2 500 tokens chacun, entraînés pendant trois époches, représentent 150 millions de tokens d’entraînement, soit environ 75 dollars par exécution. Huit exécutions pendant le développement font donc un total d’environ 600 dollars. Le calcul n’a jamais été la partie coûteuse ; c’est la préparation des données et l’évaluation qui le sont. Tout devis d’affinage basé principalement sur le coût des GPU provient de quelqu’un qui n’a jamais effectué de tel travail.

Pourquoi affiner du tout ?

Si le coût en tokens ne justifie pas l’opération, deux autres facteurs peuvent le faire.

Raison numéro un : respect strict du schéma

Cela est particulièrement important dans les travaux d’audit, mais reçoit bien moins d’attention qu’il ne le mérite.

Les modèles Frontier sont des généralistes. Si l’on leur demande de choisir parmi 51 sous-catégories fixes, ils produiront de temps en temps une 52e, car générer du texte crédible est précisément leur objectif d’entraînement. Pour un assistant de conversation, de telles erreurs ont peu d’importance. Dans un document de travail qui soutient une opinion d’audit signée, c’est en revanche un défaut.

Des recherches récentes indiquent la même chose, bien que la plupart soient des publications préliminaires et doivent être lues en tenant ce fait à l’esprit :

• Un préprint de 2026 sur la classification des documents de sécurité a évalué des modèles selon 51 sous-catégories prédéfinies, les réponses devant être fournies dans un format JSON strict. Là, un modèle affiné hébergé localement a surpassé les modèles de pointe testés par des prompts d’une marge de 15 à 20 points de pourcentage, et les chercheurs ont observé que GPT-5 inventait des noms de sous-catégories absents de la taxinomie. Leur interprétation est le point essentiel : les modèles de pointe gèrent bien l’extraction à partir de formats peu structurés, mais sous des contraintes de schéma strictes, la calibration importe plus que la capacité de raisonnement.

Un autre préprint a décrit un Qwen2.5-0.5B affiné, un modèle de cinq cents millions de paramètres qui tient sur une seule GPU grand public, atteignant en moyenne un score de 0,83 micro-F1 pour l’extraction de relations dans des domaines généraux. Avec uniquement un léger encadrement sans exemple préalable, GPT-5.4 a obtenu 0,69 sur la même mesure et Claude Sonnet 4.6 a atteint 0,66. Les auteurs soulignent que cela ne signifie pas pour autant que les petits modèles soient intrinsèquement plus puissants ; cela montre plutôt que l’adaptation d’un modèle à une tâche étroite et fixe peut compenser ses capacités brutes. L’extraction d’informations pour des audits relève précisément de ce type de tâche.

Les résultats publiés par Anthropic concernant l’affinage de Claude 3 Haiku montrent que la précision de classification pour une tâche de modération de commentaires est passée de 81,5 % à 99,6 %, avec 85 % de tokens en moins par requête. Le domaine est différent, mais le schéma reste identique.

Pour un produit d’audit, une amélioration de deux points en termes de précision de l’extraction sur le terrain peut valoir plus que toutes les dépenses liées aux inférences réunies, car chaque erreur d’extraction nécessite une revue manuelle, et la revue humaine représente la ressource la plus coûteuse dans l’entreprise.

Raison deux : connaître précisément où se trouvent les données

En Europe, c’est souvent ce qui décide de l’acceptation d’un projet.

Les fichiers d’audit d’une firme comptable britannique ou européenne contiennent des documents financiers des clients, des données sur les employés et parfois des informations personnelles concernant des tiers. Le lieu de traitement n’est pas une préoccupation secondaire ; il s’agit généralement de la deuxième question posée par les services d’achats.

Les options actuelles, en septembre 2026, surprennent de nombreuses équipes :

• L’API propriétaire d’Anthropic ne propose pas d’option de résidence en UE. Le paramètre inference_geo accepte les valeurs global ou us ; le traitement exclusivement aux États-Unis est facturé à 1,1 fois le tarif standard. Pour conserver Claude en UE, il faut utiliser une région AWS Bedrock ou Google Vertex située en UE, où les points d’accès régionaux sont facturés 10 % de plus que ceux mondiaux. Au moment de la rédaction, Microsoft Foundry ne disposait d’aucune zone de données en UE pour Claude.
• OpenAI prend en charge le traitement régional, ajoutant 10 % au prix pour les modèles lancés à partir du 5 mars 2026.
• Fireworks applique un multiplicateur de 1,5 lorsque le déploiement dédié est limité à une région.

Les GPU autonomes dans un centre de données, disons à Francfort ou Dublin englobent tous les coûts matériels et d’hébergement que vous négociez, et les données ne quittent jamais votre contrôle.

Lorsque le coût de résidence dépend du volume utilisé, la situation change. Deux cartes H100 dédiées exécutant le modèle 8B affiné, restreint à une région et fonctionnant 24 heures sur 24, coûtent environ 17 520 dollars par mois. Pour traiter la même charge de travail avec Claude Sonnet 5 sur un endpoint Bedrock en UE, le coût serait d’environ 36 080 dollars, et avec Opus 5, d’environ 90 200 dollars.

C’est là l’argument véritablement européen en faveur de la possession du modèle : ce n’est pas que les tokens soient moins chers, mais plutôt que l’explication liée à la conformité tient en une phrase plutôt qu’en un diagramme d’architecture.

N’achetez pas de GPU dédiés trop tôt

Un coût mensuel fixe pour les GPU semble attrayant, mais il piège de nombreuses équipes, car il ne devient rentable que pour des volumes que très peu de produits atteignent. En prenant comme référence un couple de GPU H100 dédiés au prix mondial, soit environ 11 680 dollars par mois, les points de bascule se situent aux alentours :

• 700 000 documents par mois pour Claude Sonnet 5, seuil en dessous duquel l’API est moins chère
• 1,4 million par mois pour Claude Haiku 4,5
• 6,6 millions par mois pour GPT-5,6 Luna

Un produit d’audit typique restera probablement en deçà de chacun de ces seuils pendant ses deux premières années. L’hébergement sans serveur d’un modèle affiné évite complètement ce piège : on obtient des poids personnalisés sans devoir payer pour des GPU inutilisés, ce qui en fait un point de départ judicieux. L’inconvénient réside dans une moindre maîtrise de la latence et de la capacité, facteurs qui ne deviennent importants que lorsque le volume est élevé et stable.

Quatre questions pour trancher

1. Quel est votre volume réel de tokens par mois ? Si vous traitez moins d’un milliard de tokens par mois, choisissez le niveau Frontier le moins cher qui permette d’obtenir les résultats souhaités, et investissez plutôt ces huit semaines d’effort d’ingénieurs dans des projets plus utiles. Le réglage fin à un volume pilote n’est qu’une formalité, pas une véritable démarche d’ingénierie.

2. À quel point la tâche est-elle restreinte et précise ? Un format de sortie fixe, un ensemble d’étiquettes prédéfini et des milliers d’exemples presque identiques par jour indiquent qu’un réglage fin est nécessaire. Le raisonnement ouvert, les décisions subjectives et la rédaction de textes destinés à être signés par un partenaire exigent plutôt un modèle Frontier, et resteront probablement dans cette catégorie.

3. Où les données doivent-elles être stockées ? Une clause contractuelle exigeant que le traitement ait lieu au sein de l’EEE modifie la liste des options possibles avant même que les coûts ne soient pris en compte. Il convient d’inclure le surcoût lié au stockage dans la première estimation, plutôt que de l découvrir lors de l’examen de l’architecture.

4. Pouvez-vous disposer d’au moins 10 000 exemples étiquetés ? Un document de recherche d’NVIDIA sur les petits modèles linguistiques dans les systèmes agents suggère qu’un nombre compris entre dix mille et cent mille exemples constitue une fourchette pratique pour ajuster un petit modèle. En l’absence de ce nombre, le premier projet devrait consister à mettre en place un système permettant d’enregistrer ses propres données d’entraînement.

Ce dernier point représente le modèle le plus précieux ici, mais aussi celui qui est le moins mis en avant. Utilisez l’API de frontière pour envoyer les données et enregistrez chaque appel, y compris les entrées, les sorties ainsi que les corrections apportées par les évaluateurs. Six mois plus tard, vous disposez d’un ensemble de données étiqueté sans coût supplémentaire, ce qui vous permet de procéder à un affinage basé sur des preuves concrètes plutôt que sur de simples espérances. L’enregistrement des documents clients impose également des obligations en matière de protection des données ; il est donc nécessaire de définir dès le début des règles de conservation et d’accès pour ces journaux.

Celui même article de NVIDIA a également estimé la part des appels aux modèles LLM que de petits modèles pourraient prendre en charge dans trois projets d’agents open source : environ 60 % pour MetaGPT, 40 % pour Open Operator et 70 % pour Cradle. Ce ne sera ni l’ensemble, ni rien du tout ; la réponse correcte est un mélange, et seuls les journaux d’activité permettent de déterminer quels appels correspondent à quel type de modèle.

Le contre-argument le plus solide

Les données relatives à l’adoption par les entreprises indiquent le contraire. Selon l’enquête menée par Menlo Ventures auprès des entreprises, la part des charges de travail utilisant du code open source est passée de 19 % à 11 %, tandis que les dépenses se sont concentrées sur des API fermées : Anthropic représente 40 % des dépenses des entreprises en matière de LLM, OpenAI 27 % et Google 21 %. (Menlo est un investisseur d’Anthropic, ce qui est utile à savoir en lisant ces chiffres.)

Cela ne contredit pas l’analyse précédente ; cela montre où réside la difficulté. Les API fermées ont l’avantage en termes de commodité, et la commodité l’emporte généralement. Les équipes qui tirent un véritable avantage des ajustements fine-tuning avec du code open source ont choisi délibérément cette charge opérationnelle, pour une raison qu’elles peuvent expliquer clairement. Si vous ne pouvez pas indiquer cette raison, l’enquête constitue un signal à prendre en compte.

Une brève note sur la réglementation de l’UE

Les équipes du Royaume-Uni et de l’UE poseront des questions concernant la loi sur l’IA, il est donc utile d’avoir un bref résumé. Considérez-le comme une introduction, et non comme un conseil juridique, et vérifiez le texte actuel avant de vous fier à toute date.

L’Omnibus numérique sur l’IA, officiellement la Règlementation (UE) 2026/1744, a été publiée au Journal officiel le 24 juillet 2026 et est entrée en vigueur trois jours plus tard, le 27 juillet. Elle a reporté les obligations relatives aux systèmes à haut risque relevant de l’Annexe III, initialement prévues pour le 2 août 2026, au 2 décembre 2027. Pour les systèmes d’IA intégrés dans des produits visés à l’Annexe I, la nouvelle date est le 2 août 2028.

Les obligations de transparence prévues à l’article 50 n’ont pas été reportées et s’appliquent depuis le 2 août 2026, comme prévu initialement. Pour les systèmes mis sur le marché plus tôt, l’obligation d’étiquetage prévue à l’article 50, paragraphe 2, entre en vigueur le 2 décembre 2026.

Les outils qui aident les auditeurs et prévoient une étape d’approbation humaine se situent généralement en dehors de l’Annexe III, mais évaluez votre propre cas d’usage : si un composant influence les décisions de recrutement ou la solvabilité, il relève du champ d’application. Rien de tout cela n’affecte le RGPD, qui régit les données des clients circulant dans le système, quel que soit le classement du système par la loi sur l’IA.

La demande est réelle. Selon une enquête de Wolters Kluwer, 39 % des 4 214 professionnels d’audit interne ont déclaré utiliser déjà l’IA, et 41 % prévoient de le faire d’ici un an.

Un plan en phases pour un tel développement

Pour une équipe qui commence à développer ce type de système, la séquence recommandée est :

1. Déployez la version la moins chère qui satisfait votre ensemble d’évaluation.** Enregistrez chaque appel de modèle, permettez aux auditeurs expérimentés de l’utiliser pendant une période chargée réelle, et reportez tout affinage.

Étudiez les journaux d’activité. Identifiez les deux ou trois types d’appels qui représentent la majeure partie des tokens et vérifiez s’ils sont répétitifs et soumis à un schéma précis. C’est presque toujours le cas.

Ajustez finement uniquement ces appels. Hébergez-les initialement sur une infrastructure serverless, laissez le tri, la rédaction et la réponse aux questions gérés par le modèle de pointe, et ajoutez un routeur devant les deux.

Adoptez des GPU dédiés uniquement lorsque le volume ou une exigence contractuelle l’exige**, et jamais avant.

Trois de ces quatre phases coûtent moins que ce que beaucoup d’équipes dépensent dès le premier jour.

Points clés

• Les modèles de pointe actuels ne peuvent généralement pas être ajustés finement, donc le véritable choix se situe entre un modèle à poids ouverts avec un adaptateur LoRA et une API hébergée.

Dans les pipelines de documents, quelques appels répétitifs liés à un schéma consomment la majeure partie des tokens ; l’analyse des coûts doit commencer par là.

Réorienter ces appels vers le niveau le moins cher mais compétent permet d’économiser bien plus que le réglage fin, et cela ne prend que des heures plutôt que des semaines.

Le réglage fin trouve son intérêt dans le respect strict du schéma et de la résidence des données, et non grâce au coût des tokens.

Les ressources de calcul nécessaires à l’entraînement sont peu coûteuses ; les données étiquetées, l’évaluation et les opérations représentent en réalité les vrais coûts.

Enregistrez dès le premier jour les appels générant des logs, afin que tout futur réglage fin puisse s’appuyer sur des preuves concrètes.

Les prix, les options de résidence et les dates réglementaires changent rapidement ; vérifiez à nouveau chaque chiffre sur les pages du fournisseur et les textes officiels avant d’engager un budget.

La question fondamentale n’a jamais été celle du modèle de petite taille contre le modèle avancé. Il s’agit plutôt de déterminer quels de vos appels nécessitent réellement une capacité de raisonnement. En y répondant, la question des coûts se résout en grande partie d’elle-même.

Lectures complémentaires

• Cartographier RAG : Étapes du pipeline, composants clés et panorama des variantes — Comprendre le fonctionnement complet de la génération augmentée par la récupération d’informations, quels composants un système RAG nécessite, et comment les nombreuses variantes de RAG s’inscrivent dans une même représentation.

Échanger les modèles de LLM en toute sécurité : étiquettes humaines, métriques par étape, réglages d’effort — Comment migrer un pipeline de LLM à plusieurs étapes vers des modèles plus récents sans subir de dégradations invisibles : vérités de référence fournies par des humains, métriques par étape, prompts obsolètes et effort de raisonnement.