Guide du catalogue de modèles IA : comment lire les fournisseurs, points de terminaison, groupes et prix

Mise à jour : 14 septembre 2026

Un Guide du catalogue de modèles IA : comment lire les fournisseurs, points de terminaison, groupes et prix est utile, car les catalogues de modèles font désormais bien plus que lister des noms. Un catalogue de production est une surface de routage. Il indique aux équipes produit, d’ingénierie et financières quel fournisseur possède la route, quelle forme d’API est prise en charge, quel groupe ou plan peut l’appeler, quelle unité est facturée, et si le modèle est suffisamment sain pour du trafic réel.

L’erreur coûteuse consiste à lire un catalogue comme un classement. Une ligne avec le nom d’un modèle célèbre peut néanmoins être inadaptée à votre charge de travail si la forme du point de terminaison ne correspond pas à votre SDK, si l’unité de facturation n’est pas comparable, si la route est limitée à un groupe que vous n’utilisez pas, ou si l’état de disponibilité n’est pas prêt pour la production.

Ce guide du catalogue de modèles IA donne aux équipes produit une méthode pratique pour lire un catalogue de modèles avant de sélectionner, tester ou router du trafic via une passerelle d’API IA. Il utilise le répertoire public de modèles et la documentation de Flatkey comme exemple de travail, mais la liste de contrôle s’applique aux catalogues directs des fournisseurs, aux catalogues de passerelle et aux catalogues de plateforme interne.

Réponse rapide : comment lire un catalogue de modèles IA

Lisez un catalogue de modèles IA dans cet ordre :

1. Fournisseur : qui exploite le modèle en amont ou la route.
2. ID du modèle : la chaîne exacte que votre application doit envoyer.
3. Prise en charge des points de terminaison : quelle forme d’API la route accepte, comme chat compatible OpenAI, Responses, Anthropic, Gemini, image, vidéo, embeddings ou une route native.
4. Groupe ou plan : quel groupe de compte, groupe de routes, groupe de quota ou plan de facturation peut utiliser la ligne.
5. État de disponibilité : si la route est en service, dégradée, inconnue, en aperçu, en accès anticipé, obsolète ou bientôt disponible.
6. Unité de tarification : si la facturation se fait par 1 M de jetons d’entrée/de sortie, jetons mis en cache, image, seconde, requête, caractère, minute ou une autre unité.
7. Preuve d’utilisation : si votre requête de test apparaît dans les journaux avec le modèle attendu, l’état, les comptages de jetons, la route, la clé et le coût.

La réponse courte dans ce Guide du catalogue de modèles IA : comment lire les fournisseurs, points de terminaison, groupes et prix est la suivante : ne choisissez pas un modèle uniquement à partir de la colonne des prix. Choisissez-le après que le fournisseur, le point de terminaison, le groupe, l’état, l’unité de prix et la preuve dans les journaux d’utilisation soient tous cohérents avec votre charge de travail.

Aperçu actuel du catalogue de modèles Flatkey

La documentation actuelle de Flatkey décrit une base URL unique compatible OpenAI, https://router.flatkey.ai/v1, ainsi que des points de terminaison API pour les complétions de chat, Responses, les embeddings, la génération d’images, les tâches vidéo et la सूची des modèles. Le point de terminaison /v1/models renvoie les ID de modèles et les fournisseurs dans un format compatible OpenAI, tandis que le répertoire de modèles public est l’endroit en direct pour consulter les prix, l’état de santé, la prise en charge des points de terminaison et les pages de détail des modèles.

Le 14 septembre 2026, le répertoire public de modèles de Flatkey exposait des champs de ligne directement pertinents pour l’examen du catalogue :

Considérez cet instantané comme une preuve de la structure du catalogue, et non comme un tableau de prix permanent. La documentation de référence de Flatkey renvoie explicitement les lecteurs vers flatkey.ai/models, flatkey.ai/pricing et flatkey.ai/status afin que les lignes de modèles, les tarifs et l’état de santé puissent être mis à jour sans nouvelle version de la documentation.

Lisez les fournisseurs avant de lire les noms des modèles

Le fournisseur est le premier champ, car un nom de modèle seul ne vous dit pas où le trafic va, quel contrat s’applique ni quelles limites opérationnelles comptent.

Utilisez le champ fournisseur pour répondre à :

Pour Flatkey, le positionnement approuvé est une clé, un solde et un accès officiel aux modèles auprès de fournisseurs tels qu’OpenAI, Anthropic, Google, DeepSeek, Alibaba, Z.ai, Moonshot et ByteDance. Cela rend la transparence du fournisseur particulièrement importante. Si une ligne du catalogue ne rend pas le fournisseur et la classe d’itinéraire clairs, demandez une clarification avant d’approuver la ligne pour la production.

Lisez les points de terminaison comme des contrats, pas comme des étiquettes

La prise en charge des points de terminaison est un contrat entre votre application et la route. Elle détermine si votre client actuel, le corps de requête, le gestionnaire de streaming, le parseur d’appels d’outils et la logique de comptabilisation de l’usage peuvent fonctionner sans réécriture.

La documentation REST de Flatkey répertorie les points de terminaison d’API publics suivants :

Une ligne de catalogue qui indique openai n’est pas la même qu’une ligne qui indique anthropic, gemini, openai-response, openai-video ou video. Un modèle peut prendre en charge plusieurs familles de points de terminaison, mais vous devez tout de même tester le chemin exact que votre application utilisera.

Pour ce guide du catalogue de modèles IA, utilisez le champ de point de terminaison pour rédiger un court contrat de compatibilité :

catalog_endpoint_contract:
  workload: support_ticket_summary
  model_id: selected-model-id
  provider: provider-name
  endpoint_type: openai
  base_url: https://router.flatkey.ai/v1
  endpoint_path: /v1/chat/completions
  required_features:
    - streaming
    - tool_calls
    - structured_json
    - usage_fields
  pass_condition:
    - existing_sdk_initializes
    - response_parser_accepts_output
    - usage_log_matches_model
    - fallback_policy_is_documented

Si un élément de ce contrat échoue, le modèle peut malgré tout rester utile, mais il ne s’agit pas d’une route prête à l’emploi pour cette charge de travail.

Lire les groupes comme une politique de route et de coût

Les groupes sont faciles à ignorer parce qu’ils ressemblent à des libellés internes de plateforme. Ne les ignorez pas. Un groupe peut décider qui peut utiliser une route, quel multiplicateur de prix s’applique, quelle clé est autorisée, quel quota est consommé et quel pool de secours est disponible.

Dans un catalogue de passerelle, les groupes représentent souvent une ou plusieurs de ces politiques :

Le positionnement produit de Flatkey inclut la gouvernance des sous-clés, les budgets, les listes d’autorisation de modèles, les journaux d’utilisation et un solde partagé. Cela signifie que la ligne du catalogue et le tableau de bord d’utilisation doivent être cohérents. Si un chef de produit approuve un modèle dans le catalogue mais que la clé de production n’est pas dans le bon groupe, l’équipe d’ingénierie découvrira le problème sous forme de 403, 429, d’échec de fallback ou de mauvaise surprise de facturation.

Lire les prix par unité avant de comparer les lignes

Le prix est le champ du catalogue de modèles le plus souvent mal interprété. Un guide du catalogue de modèles IA devrait obliger chacun à ramener chaque prix à sa véritable unité avant toute comparaison.

Ne comparez pas ces unités comme si elles étaient identiques :

Les pages de tarification des fournisseurs utilisent aussi des appellations différentes. OpenAI, Anthropic, Google Gemini et DeepSeek séparent tous, dans leur documentation tarifaire publique actuelle, une combinaison de tarification pour l’entrée, la sortie, l’entrée mise en cache, la lecture/écriture du cache ou les cache hit/cache miss. C’est pourquoi une revue du catalogue devrait enregistrer l’URL source en direct et la date de révision au lieu de recopier un prix permanent dans une tâche de feuille de route.

Utilisez cette formule normalisée :

accepted_workload_cost =
  (primary_attempt_cost
   + retry_cost
   + fallback_cost
   + cached_or_uncached_delta
   + media_or_tool_addons)
  / accepted_outputs

Puis ajoutez le contexte de décision :

production_cost_decision =
  accepted_workload_cost
  + latency_penalty
  + manual_review_cost
  + incident_risk
  + data_policy_constraints

C’est pour cela que la cellule de prix la moins chère est rarement la réponse finale.

Lire le statut avant le trafic de production

Le statut de disponibilité doit être un critère de blocage, pas une note de bas de page. Un modèle peut sembler parfait sur le fournisseur, le point de terminaison et le prix, tout en restant le mauvais choix pour la production s’il est uniquement en preview, dégradé, limité à une région, obsolète, absent de votre compte ou en échec de vérification de santé.

Utilisez ces classes de statut :

La documentation de Flatkey indique les contrôles d’intégrité des modèles vers la page d’état en direct. Pour une décision de production, le champ de statut doit être enregistré avec la date, l’ID du modèle, le type de point de terminaison, la clé ou le groupe, et un identifiant de requête réel.

Un workflow Flatkey pour la revue du catalogue

Utilisez ce workflow chaque fois qu’une équipe produit demande si un modèle du catalogue peut être utilisé en toute sécurité.

1. Ouvrez le répertoire des modèles Flatkey.
2. Recherchez l’ID exact du modèle, pas seulement le nom du fournisseur.
3. Enregistrez le fournisseur, la prise en charge des points de terminaison, le statut de disponibilité, l’unité de tarification, l’accès au groupe et la date de revue actuelle.
4. Ouvrez la tarification Flatkey et la page de tarification du fournisseur concerné.
5. Notez l’unité de coût normalisée : par 1 M de jetons d’entrée, jetons de sortie, jetons mis en cache, image, seconde, requête ou autre unité.
6. Exécutez un test de fumée à faible risque via le base_url, le chemin du point de terminaison et l’ID du modèle prévus.
7. Confirmez que la requête apparaît dans les journaux d’utilisation Flatkey avec le modèle, la clé, le statut, les nombres de jetons ou l’unité média, et le coût attendus.
8. Définissez les règles de repli avant d’envoyer de vrais utilisateurs : déclencheur, nombre de tentatives, modèles de repli autorisés, seuil de qualité et champs de journalisation.
9. Examinez l’enregistrement du catalogue avec les équipes produit, ingénierie, finance et sécurité avant de définir cette route comme valeur par défaut.

Le point important est l’étape 7. Une ligne du catalogue est une promesse. Une ligne de journal d’utilisation est la preuve que la promesse correspondait à votre compte, votre clé, votre groupe et votre charge de travail.

Modèle : fiche de revue du catalogue de modèles IA

Copiez ce modèle dans un document de lancement interne :

ai_model_catalog_review:
  review_date: 2026-09-14
  reviewer: product_owner_or_platform_owner
  workload: customer_support_summary
  business_owner: support_product
  environment: staging
  catalog:
    catalog_url: https://flatkey.ai/models
    model_id: selected-model-id
    provider: provider-name
    endpoint_types:
      - openai
    group_or_plan: approved-group
    availability_status: available
    pricing_unit: per_1m_input_and_output_tokens
  compatibility:
    base_url: https://router.flatkey.ai/v1
    endpoint_path: /v1/chat/completions
    sdk: openai-python
    streaming_required: true
    tool_calls_required: false
    structured_output_required: true
  cost:
    provider_pricing_url: provider-pricing-page
    flatkey_pricing_url: https://flatkey.ai/pricing
    cost_formula: accepted_workload_cost
    cache_assumption: measured_not_assumed
  evidence:
    smoke_test_request_id: req_example
    usage_log_verified: true
    output_parser_passed: true
    p95_latency_ms: measured
    fallback_tested: false
  decision:
    status: approve_for_limited_rollout
    rollout_limit: 5_percent_of_traffic
    fallback_route: selected-fallback-model
    next_review_date: 2026-09-21

Ce modèle conserve l’aspect pratique du Guide du catalogue de modèles IA : comment lire les fournisseurs, points de terminaison, groupes et prix. Le résultat n’est pas une liste de préférences. C’est un compte rendu de décision vérifiable.

Erreurs courantes dans le catalogue de modèles IA

Erreur 1 : Traiter le fournisseur et la famille de modèles comme s’il s’agissait du même champ

Le fournisseur est le propriétaire en amont ou le propriétaire de la route. La famille de modèles est un groupe de dénomination. Ils sont liés, mais ne sont pas interchangeables. Enregistrez les deux.

Erreur 2 : Supposer qu’être compatible avec OpenAI signifie que tous les points de terminaison fonctionnent

Une configuration compatible avec OpenAI peut réduire le travail de migration, mais elle ne prouve pas que chaque point de terminaison, événement de streaming, forme d’appel d’outil, champ d’utilisation ou paramètre multimédia fonctionne pour chaque modèle. Testez la famille de points de terminaison exacte dans la ligne du catalogue.

Erreur 3 : Comparer le prix des jetons au prix des médias

La facturation par jeton, par image, par seconde et par requête ne doit pas être réduite à une seule colonne de prix. Normalisez en coût par sortie acceptée pour la charge de travail.

Erreur 4 : Ignorer les groupes jusqu’au déploiement

Si la clé de production n’est pas autorisée à appeler le groupe que vous avez approuvé, la décision du catalogue est incomplète. Validez l’accès au groupe avec la clé qui sera réellement déployée.

Erreur 5 : Copier une ligne de prix sans date de révision

Les prix du fournisseur et de la passerelle peuvent changer. Enregistrez l’URL source, la date de révision, l’ID du modèle, l’unité tarifaire et la preuve du journal d’utilisation issue d’une requête de test.

Erreur 6 : Mettre en production en se basant uniquement sur le statut du catalogue

Le statut du catalogue doit déclencher le test de validation. Il ne doit pas le remplacer. L’approbation de production nécessite au moins une requête passant par la même clé, le même point de terminaison, le même modèle et le même groupe.

Quand un catalogue unifié de modèles IA est le plus utile

Un catalogue unifié de modèles est le plus utile lorsqu’une équipe rencontre plus d’un de ces problèmes :

• Des clés de fournisseurs multiples sont dispersées entre les services, les agents et les environnements.
• Le produit veut comparer les routes texte, image, vidéo, embedding et outils dans un seul workflow.
• La finance veut des preuves de coût au niveau de la requête plutôt que des factures distinctes par fournisseur.
• L’ingénierie plateforme a besoin de règles de secours, de vérifications de santé et de listes d’autorisation de modèles.
• La sécurité doit savoir quelle route a traité quelle charge de travail.
• Les équipes doivent pouvoir passer d’un modèle à un autre sans réécrire chaque client.

Flatkey est positionné pour ce schéma : une clé API, un routeur compatible OpenAI, un annuaire de modèles en direct, des journaux d’utilisation, l’accès aux modèles/outils via un seul solde, et des contrôles opérationnels pour les équipes. Cela ne supprime pas la diligence raisonnable. Cela donne à l’équipe un seul endroit pour la réaliser.

FAQ

Qu’est-ce qu’un catalogue de modèles IA ?

Un catalogue de modèles IA est une liste consultable de routes de modèles et de leurs métadonnées : ID du modèle, fournisseur, endpoints pris en charge, unité de tarification, disponibilité, groupes ou plans, et parfois fenêtre de contexte, modalité, état de santé, limites et liens d’utilisation.

Pourquoi le champ fournisseur est-il important ?

Le champ fournisseur indique qui possède le modèle ou la route en amont. Il a une incidence sur le support, les références de tarification, les limites, les notifications de cycle de vie, le comportement régional, la gestion des données et la réponse aux incidents.

Que signifie la prise en charge des endpoints dans un catalogue de modèles ?

La prise en charge des endpoints indique quelle forme d’API une ligne de modèle accepte. Par exemple, une ligne peut prendre en charge le chat compatible OpenAI, Responses, les requêtes compatibles Anthropic, les requêtes natives Gemini, la génération d’images, la génération vidéo ou les embeddings. Votre SDK et votre parseur doivent correspondre à l’endpoint choisi.

Les groupes sont-ils identiques aux niveaux de tarification ?

Parfois, mais pas toujours. Les groupes peuvent représenter des plans commerciaux, des pools de routes, des politiques d’accès, des périmètres de clé, des périmètres de budget ou des familles de secours. Traitez les groupes comme une politique de route jusqu’à ce que le propriétaire de la plateforme confirme la signification exacte.

Comment les équipes doivent-elles comparer les prix des modèles ?

Comparez les prix des modèles par charge de travail, et non par simple ligne brute du catalogue. Normalisez les jetons d’entrée, les jetons de sortie, les jetons mis en cache, les images, les secondes, les requêtes, les tentatives de relance, les tentatives de secours et les sorties acceptées dans une seule formule de coût.

Dois-je faire confiance à une ligne du catalogue de modèles sans test ?

Non. Une ligne du catalogue est un point de départ utile, mais l’approbation en production doit inclure un test de fumée via la clé exacte, l’URL de base, l’endpoint, l’ID du modèle et le groupe que vous prévoyez d’utiliser.

Comment Flatkey aide-t-il à la revue du catalogue de modèles ?

Flatkey offre aux équipes un seul endroit pour inspecter les lignes de modèles, router via une URL de base compatible OpenAI, comparer les surfaces de tarification en direct, vérifier la santé des modèles et consulter les journaux d’utilisation. Cela facilite l’audit des décisions de catalogue entre le produit, l’ingénierie et la finance.

Étape finale de revue du catalogue

L’étape finale d’un Guide du catalogue de modèles IA : comment lire les fournisseurs, points de terminaison, groupes et prix n’est pas de choisir un modèle. C’est de prouver la route.

Avant le lancement, votre équipe devrait pouvoir montrer :

• L’ID exact du modèle et le fournisseur.
• Le type d’endpoint et le chemin SDK.
• Le groupe ou plan qui accorde l’accès.
• L’unité de tarification actuelle et l’URL source.
• L’état de disponibilité et la date de revue.
• Un ID de requête de test de fumée.
• Une ligne de journal d’utilisation montrant le modèle, la clé, le statut, les jetons ou l’unité média, et le coût.
• Une règle de secours et de retour arrière.

Si ces champs sont complets, le catalogue fait son travail. S’ils sont manquants, le choix du modèle reste une supposition.

Sources consultées

• Présentation de l’API REST Flatkey
• Point de terminaison Flatkey List Models
• Guide du SDK OpenAI Flatkey
• Documentation du tableau de bord d’utilisation et des coûts Flatkey
• Répertoire des modèles en direct Flatkey
• Tarification Flatkey
• État des modèles Flatkey
• Tarification de l’API OpenAI
• Tarification Anthropic
• Tarification de l’API Google Gemini
• Tarification de l’API DeepSeek