Le choix du modèle était autrefois une préférence d’ingénieur. En 2026, c’est une décision de gouvernance et de compte de résultat — surtout pour les opérateurs qui font tourner des agents sur du vrai volume. Cet article pose le calcul de coût que nous utilisons avec nos clients : modèles à poids ouverts par défaut, frontier quand ça se justifie, avec des chiffres étiquetés illustratifs sauf quand ils sont liés à des tarifs publiés.
Pour le contexte d’architecture, lisez la page de la stack hybride ouverte et notre article sur le choix du modèle comme décision de gouvernance.
Deux catégories, une seule couche de routage
| Catégorie | Exemples | Charge typique |
|---|---|---|
| Cœur à poids ouverts | Llama, Mistral, Qwen, classe GLM | Triage, étiquetage, extraction, brouillons standards, fort volume |
| API frontier | Claude, GPT, Gemini | Chaînes complexes, ton délicat, raisonnement multi-étapes ambigu |
L’erreur est de choisir un seul fournisseur pour tout. La discipline, c’est le routage par appel avec journalisation — ce que la Couche Opérationnelle d’IA est conçue pour porter.
Économie illustrative par appel
Les prix des fournisseurs bougent chaque semaine ; traitez le tableau comme un ordre de grandeur, à vérifier avant de budgéter :
| Classe de tâche | Routage open (illustratif) | Routage frontier (illustratif) | Ratio |
|---|---|---|---|
| Classification en une passe | $/1M tokens bas | $/1M tokens moyen | ~3–5× |
| Résumé de long fil de discussion | Moyen | Élevé | ~4–8× |
| Chaîne d’étapes agent multi-outils | Moyen-élevé | Élevé | ~6–12× |
Notre contenu produit utilise ~6–12× comme référence de stack hybride quand le même workflow est routé entièrement vers le frontier vs un modèle ouvert bien choisi pour l’essentiel des appels — pas une promesse sur votre facture.
Le calcul de coût mixte (~80/20)
Supposons un workflow avec 10 000 appels de modèle/mois, coût normalisé de 1 unité par appel open et 8 unités par appel frontier (8× illustratif) :
| Stratégie | Calcul | Coût d’inférence relatif |
|---|---|---|
| 100 % open | 10 000 × 1 | 10 000 |
| 100 % frontier | 10 000 × 8 | 80 000 |
| 80 % open / 20 % frontier | 8 000×1 + 2 000×8 | 24 000 (~70 % sous le tout-frontier) |
Les mix réels dépendent des étapes qui méritent vraiment le frontier. La finance se soucie de la ligne mixte, pas de la démo qui n’utilisait que le modèle premium.
Résidence des données et l’option ouverte
Les API frontier signifient souvent que les données quittent votre région choisie selon les conditions du fournisseur. Les modèles ouverts performants peuvent tourner :
- Dans votre tenant cloud (UE, UK, US selon accord)
- Via des fournisseurs d’inférence hébergés dans l’UE
- On-prem là où capital et opérations le justifient
La résidence n’est pas gratuite — mais elle est choisible d’une façon que les défauts frontier mono-fournisseur ne sont parfois pas. Cela compte pour les données voyageurs en hôtellerie, les RH, et les workflows liés à la santé.
Quand le frontier gagne (liste honnête)
Routez vers les API premium quand la plupart ou toutes ces conditions s’appliquent :
- Plus de trois étapes d’outils dépendantes avec un coût d’échec
- Risque de ton réputationnel (réclamation, communication B2B exécutive)
- Ambiguïté où une mauvaise classification coûte plus que l’écart de token
- L’évaluation montre que le modèle ouvert manque la précision convenue sur des cas représentatifs
Si aucune de ces conditions ne s’applique, l’open est généralement la bonne réponse par défaut — prouvez-le dans les évaluations du pilote, pas dans le marketing du fournisseur.
Quand l’open gagne
- Classification et étiquetage à fort volume
- Extraction structurée avec validation humaine sur les exceptions
- Brouillons standards depuis des modèles approuvés
- Premier passage open, puis « passe de révision » frontier plus petite sur les cas difficiles
Le schéma : premier passage open, second passage frontier sur les éléments signalés — réduit le coût sans cacher les cas difficiles.
Exigences opérationnelles (peu glamour, obligatoires)
Router sans observabilité, c’est deviner :
- Journalisez modèle, tokens, coût estimé, nom d’outil par appel
- Un tableau de bord ou un export hebdomadaire que la finance peut lire
- Des métriques de file de revue (taux d’approbation, taux de correction) liées aux changements de modèle
- Relancez le jeu d’évaluation quand prompts, outils ou modèles changent
C’est le même niveau d’exigence que nous fixons dans les missions de gouvernance IA — le choix du modèle est un objet de politique, pas un secret de développeur.
Le coût sur le tableau avant le pilote
Le Discovery doit produire :
- Un diagramme de workflow avec l’assignation de modèle par étape
- Une bande d’inférence mensuelle illustrative (open, frontier, mixte)
- Des critères pour promouvoir une étape vers le frontier ou la rétrograder vers l’open après revue
Les chiffres de projet d’époque (contexte, pas une offre actuelle) restent dans le corps de cette note. Le travail public actuel est un devis Web & eCommerce ou US → EMEA.
Erreurs courantes
- Tout frontier parce que la démo avait l’air plus intelligente — la facture monte linéairement avec le volume.
- Tout open sur des brouillons externes sensibles au ton — le travail de correction mange les économies.
- Pas de jeu d’évaluation — vous découvrez l’échec en semaine trois de la saison, pas au labo.
- Routage seulement dans les prompts — sans journaux de passerelle, finance et sécurité ne peuvent pas auditer.
Si l’économie des modèles bloque votre dossier business, demandez un devis de pack ou lisez la page de la stack ouverte, conservée comme contexte.
Questions fréquentes
Les modèles ouverts sont-ils assez bons pour des agents en production ?
Pour la classification, l'extraction et les brouillons standards — souvent oui, quand outils et évaluation sont bien conçus. Les modèles frontier se justifient sur le raisonnement complexe, le ton délicat ou les longues chaînes d'outils dépendantes — pas sur chaque appel par défaut.
Quel est un mix open/frontier réaliste ?
Schéma de conception illustratif : ~80 % open / ~20 % frontier en volume d'appels peut atterrir ~70 % en dessous d'une inférence tout-frontier pour une charge similaire — pas une économie garantie ; dépend du mix de tâches et de la discipline de routage.
L'auto-hébergement de modèles ouverts élimine-t-il le coût ?
Ça change la courbe : pas de facture fournisseur au token, mais du capital GPU/hébergement et des opérations. Les équipes mid-market démarrent souvent avec des API ouvertes hébergées dans une région convenue, puis évaluent l'auto-hébergement si le volume le justifie.
Comment décider par workflow ?
Le Discovery cartographie sensibilité, latence, langue et coût d'erreur. Mettez le choix de modèle par workflow et l'inférence mensuelle attendue sur le tableau avant le pilote — la même discipline que celle décrite sur la page produit de la stack ouverte.