Évaluation des modèles d’IA avant de changer de fournisseur d’API : checklist de workflow

Changer de fournisseur d’API d’IA n’est pas une décision de classement des modèles. C’est un changement de production qui peut modifier en même temps la qualité des sorties, la validité du JSON, les appels d’outils, la latence, le comportement de limitation de débit, la gestion des erreurs et le coût total.

L’approche la plus sûre consiste à transformer le changement proposé en test d’acceptation répétable. Exécutez l’actuel et le candidat sur les mêmes cas représentatifs de production, évaluez les résultats complets du workflow, définissez des seuils de migration stricts avant de voir les résultats, et exposez progressivement le candidat derrière une route prête au retour arrière.

Ce guide vous donne ce processus, y compris une grille de score, la conception du jeu de données, une matrice de compatibilité, une méthode de test par paires, une formule de coût, des étapes de déploiement et une note de décision.

La réponse courte : utilisez un test d’acceptation pour changement de fournisseur

Avant de déplacer le trafic de production, exigez que la route candidate passe cinq contrôles :

1. Qualité du workflow : elle réalise la tâche utilisateur avec un taux acceptable sur des entrées représentatives.
2. Compatibilité contractuelle : les sorties structurées, les appels d’outils, le streaming, les erreurs et les états de fin fonctionnent avec votre application.
3. Fiabilité opérationnelle : la latence, les timeouts, les limites de débit, les tentatives et la concurrence restent dans les objectifs de votre service.
4. Valeur économique : le coût effectif par tâche acceptée s’améliore ou reste dans un compromis approuvé.
5. Déploiement sécurisé : le trafic fantôme et un canari par étapes montrent que les résultats hors ligne survivent aux conditions de production.

N’approuvez pas un changement parce que le candidat gagne un benchmark public, produit quelques réponses impressionnantes ou affiche un prix de jeton annoncé plus bas. Ces signaux peuvent aider à établir une liste restreinte. Ils ne prouvent pas que le fournisseur peut exécuter votre workflow.

Commencez par la décision de migration, pas par la liste des modèles

Rédigez une décision en une phrase avant de construire l’évaluation :

Remplacer la route A par la route B pour le workflow X si B n’est pas inférieur en réussite de tâche, passe toutes les validations contractuelles, respecte le budget de latence et de fiabilité en production, et réduit le coût effectif par tâche acceptée du montant requis.

Cette phrase oblige l’équipe à définir le périmètre. Un fournisseur peut convenir à l’extraction mais pas à l’utilisation agentique d’outils, ou à l’enrichissement par lots mais pas à un assistant interactif. Évitez une conclusion universelle du type « meilleur modèle » lorsque la vraie décision concerne une route, une charge de travail et une enveloppe d’exploitation précises.

Consignez ces entrées dans le plan d’évaluation :

Si le changement d’intégration lui-même est encore incertain, consultez la checklist de migration d’une passerelle API compatible avec OpenAI avant de tester les modèles. Une interface partagée réduit les changements de code, mais elle ne rend pas le comportement des modèles identique.

Définir l’unité d’évaluation comme une trace complète

L’unité d’évaluation doit correspondre à ce que votre client expérimente. Pour un classificateur à tour unique, cela peut être une requête et une réponse. Pour un agent, cela peut être une trace entière contenant plusieurs appels au modèle, des invocations d’outils, des tentatives de reprise et une réponse finale.

Un enregistrement de trace utile comprend :

{
  "case_id": "support-refund-042",
  "segment": "refund-policy",
  "input": {},
  "expected_contract": {},
  "route": "candidate-b",
  "attempts": 1,
  "latency_ms": 1840,
  "input_tokens": 3120,
  "output_tokens": 486,
  "provider_cost_usd": 0.0124,
  "schema_valid": true,
  "tool_sequence_valid": true,
  "task_success": true,
  "failure_class": null
}

Cela évite une erreur de mesure courante : noter uniquement la prose finale tout en ignorant les arguments mal formés, les outils répétés, les reprises cachées ou un pic de latence qui a rendu le workflow inutilisable.

Construire un jeu de tests représentatif de la production

L’ensemble d’évaluation doit représenter la distribution et les modes de défaillance du parcours que vous prévoyez de migrer. Sélectionner au hasard une petite pile de prompts « typiques » masque généralement les cas qui provoquent des incidents.

Utilisez six groupes de cas :

1. Cas fréquents : Les entrées responsables de la majeure partie du trafic normal.
2. Cas à forte valeur : Les tâches où une mauvaise réponse entraîne une correction humaine coûteuse ou une perte de conversion.
3. Cas de longue traîne : Langues, formats, domaines ou intentions utilisateur rares.
4. Cas de contrat : Entrées qui mettent à l’épreuve les schémas, les énumérations, les objets imbriqués, les outils et l’assemblage du streaming.
5. Cas adversariaux : Instructions ambiguës, preuves contradictoires, injection de prompt et requêtes non prises en charge.
6. Cas opérationnels : Contexte volumineux, sorties longues, rafales concurrentes, timeouts et erreurs côté fournisseur.

Segmentez le jeu de données afin que chaque segment important dispose d’assez d’exemples pour être examiné séparément. Un candidat peut sembler acceptable dans l’ensemble tout en échouant pour une langue, un outil ou un niveau de clientèle.

Conservez trois couches de jeu de données :

• Jeu de développement : cas visibles utilisés pour améliorer les prompts et les validateurs.
• Jeu de décision : cas mis de côté utilisés pour approuver ou rejeter la migration.
• Jeu d’audit de production : nouveaux cas échantillonnés après le déploiement pour détecter la dérive.

Ne continuez pas à ajuster à plusieurs reprises en fonction du jeu de décision. Une fois que l’équipe a vu ses échecs et a modifié le système, ces cas sont de fait devenus des données de développement.

Figez les conditions de test

Les comparaisons par paires ne sont utiles que lorsque le système en place et le candidat reçoivent un travail équivalent. Figez ou consignez :

• Les instructions système et développeur.
• L’entrée utilisateur et les pièces jointes.
• Les définitions d’outils et les schémas JSON.
• La température, la sortie maximale, la graine lorsqu’elle est prise en charge, et les paramètres de raisonnement.
• Les résultats de récupération et l’ordre des documents.
• La région, la version de l’API, l’identifiant du modèle et la route du fournisseur.
• La politique de nouvelle tentative, le délai d’attente et la concurrence.
• L’horodatage de l’évaluation et la source de tarification.

Si une route utilise un prompt différent parce que le fournisseur l’exige, versionnez les deux prompts et considérez cette différence comme faisant partie du package de migration. La décision métier porte sur le nouveau système, pas sur un modèle abstrait isolé de son intégration.

Faites passer chaque cas par les deux routes. Randomisez ou masquez la présentation lorsque des humains évaluent des sorties subjectives, afin que les examinateurs ne soient pas influencés par les noms des fournisseurs.

Définissez des seuils bloquants avant les scores pondérés

Un score pondéré est utile pour arbitrer, mais il ne doit pas permettre à un modèle bon marché de compenser un échec critique de contrat.

Définissez d’abord des seuils non négociables. Des seuils d’exemple pourraient inclure :

• Aucune exécution d’outil non autorisée.
• Aucun secret ni donnée restreinte dans les sorties.
• Le JSON requis est analysé et validé par rapport au schéma de production.
• Les langues requises restent au-dessus de leur seuil minimal de réussite de la tâche.
• Les taux de délai d’attente et d’erreur serveur restent dans le budget approuvé.
• Le client gère correctement la terminaison du streaming et les erreurs du fournisseur.
• Un chemin de retour en arrière est testé avant l’exposition en production.

Les seuils doivent provenir du risque de votre produit et de la base de référence actuelle. Les chiffres ci-dessous constituent un tableau de bord illustratif, et non des recommandations universelles :

Publiez les poids et les seuils avant l’exécution finale. Les modifier après l’arrivée des résultats transforme l’évaluation en justification.

Vérifiez les objectifs des scores avant d’utiliser des juges de modèle

Utilisez des validateurs déterministes partout où c’est possible :

• Analyse JSON et validation JSON Schema.
• Correspondance exacte ou normalisée des champs.
• Vérifications de tolérance numérique.
• Validation des citations et des URL.
• Validation des outils autorisés et des arguments.
• Vérifications de la séquence des outils et du nombre maximal d’étapes.
• Compilation de code, tests unitaires et exécution en bac à sable.
• Règles de politique et détecteurs de contenu interdit.
• Couverture des preuves de récupération.

Utilisez une revue humaine ou un évaluateur basé sur un modèle pour les critères qui ne peuvent pas être ramenés à une vérification déterministe, comme la clarté, le ton, la synthèse ou le fait qu’une réponse suive des consignes nuancées.

Lors de l’utilisation d’un évaluateur de modèle :

1. Donnez-lui une grille étroite avec des conditions de réussite observables.
2. Calibrez-le sur un échantillon noté par des humains.
3. Masquez l’identité du fournisseur lorsque c’est possible.
4. Conservez les prompts de l’évaluateur, la version du modèle et le raisonnement brut.
5. Envoyez les désaccords et les cas limites à une revue humaine.

Les recommandations d’évaluation d’OpenAI préconisent des évaluations spécifiques à la tâche et une évaluation continue, tandis qu’Anthropic recommande également de définir des critères de réussite observables et de construire les évaluations autour d’eux. L’implication pratique est simple : votre grille doit décrire le résultat de workflow dont vous avez besoin, et non une intelligence générique.

Comparez les résultats appariés et l’incertitude

Un score moyen seul peut masquer l’instabilité. Comme les deux routes traitent les mêmes cas, comparez-les cas par cas.

Pour la réussite binaire d’une tâche, créez un tableau apparié :

Les deux groupes de désaccord sont particulièrement utiles. Examinez-les manuellement et classez la cause racine avant d’approuver le changement.

Pour obtenir un résultat exploitable pour une décision, signalez un intervalle de confiance autour de la différence de taux de réussite des tâches, du coût et de la latence. Un bootstrap sur les identifiants de cas est une méthode pratique, car il peut préserver la structure appariée sans supposer que chaque métrique suit une distribution normale.

Utilisez une règle de non-infériorité lorsque la solution candidate offre un avantage clair, comme un coût plus faible ou une meilleure disponibilité régionale, et que le produit peut tolérer une faible différence de qualité bornée. Définissez la marge autorisée avant le test. N’approuvez que lorsque l’intervalle de confiance ne franchit pas la limite de régression inacceptable.

Examinez également les résultats par segment. Un succès global ne doit pas masquer un cas contractuel, une langue, un outil ou un workflow à forte valeur ayant échoué.

Utiliser une taxonomie des échecs au niveau de la trace

Chaque cas ayant échoué doit recevoir une classe d’échec principale. Une taxonomie cohérente transforme l’évaluation en travail d’ingénierie plutôt qu’en débat d’anecdotes.

Suivez à la fois la première défaillance et le résultat final de la trace. Une relance qui récupère une requête consomme tout de même du temps et de l’argent, et une récupération répétée peut devenir un problème de capacité en production. Le guide des limites de débit des LLM explique comment distinguer le RPM, le TPM, la mise en file d’attente, les relances et le comportement de repli.

Tester la compatibilité du fournisseur sous forme de matrice

Un point de terminaison compatible avec OpenAI peut réduire le travail de migration, mais la compatibilité n’est pas binaire. Testez les fonctionnalités exactes que votre application utilise.

La documentation Google sur les sorties structurées, par exemple, indique que la prise en charge du schéma repose sur un sous-ensemble de JSON Schema. C’est pourquoi vous devez tester votre schéma réel plutôt que de supposer qu’un schéma accepté par un fournisseur se comportera de manière identique partout.

Calculer le coût effectif par tâche acceptée

Le prix des tokens n’est qu’un composant de l’économie de la migration. Mesurez le coût total d’obtention d’un résultat exploitable :

coût effectif par tâche acceptée =
  (utilisation du modèle
   + réessais
   + utilisation de secours
   + coûts des outils et de la recherche
   + appels d’évaluation ou de modération
   + coût d’infrastructure incrémental)
  / tâches acceptées

Estimez également le coût de revue humaine généré par des résultats peu fiables ou mal formés. Un candidat avec des tokens moins chers peut revenir plus cher s’il augmente les réessais, les boucles d’outils, les files de revue ou les sorties rejetées.

Pour les prix actuels des routes, utilisez la comparaison des prix des API d’IA comme point de départ, puis confirmez le modèle et le prix exacts au moment de la décision. Enregistrez l’horodatage de la tarification avec vos résultats, car les prix et la disponibilité des modèles peuvent changer.

Déclarez le coût par segment ainsi que le coût global. Les cas à long contexte, les tâches multilingues, les entrées d’image et les traces d’agent peuvent faire ressortir un gagnant différent de celui des requêtes de texte court.

Tester la charge du candidat selon la politique de réessai réelle

Les tests de qualité hors ligne s’exécutent généralement lentement et de manière séquentielle. La production, non.

Répétez un sous-ensemble représentatif à la concurrence attendue et maximale. Mesurez :

• Latence de trace de bout en bout aux p50, p95 et p99.
• Temps jusqu’au premier token et temps de complétion lorsque le streaming est important.
• Temps d’attente en file versus temps fournisseur.
• Réponses de limitation de débit et comportement de Retry-After.
• Timeouts, échecs de connexion et erreurs 5xx en amont.
• Nombre de réessais et taux de récupération après réessai.
• Effets de bord dupliqués causés par des actions d’outils réessayées.
• Fréquence de basculement et route finale réussie.

Utilisez le même comportement de reprise bornée que celui prévu pour la production. Des tentatives illimitées peuvent donner l’impression que le taux de réussite est bon tout en violant les contraintes de latence et de coût. Si le candidat nécessite des paramètres de reprise ou de mise en file d’attente sensiblement différents, intégrez ce changement opérationnel dans la décision de migration.

Exécuter un trafic fantôme avant un canary

Les tests fantômes envoient une copie des entrées de production éligibles au candidat pendant que l’outil en place sert toujours l’utilisateur. Cela révèle des distributions de prompts réalistes et le comportement du fournisseur sans permettre que la sortie du candidat affecte le client.

Protégez le chemin fantôme :

• Excluez le trafic sensible, sauf si les contrôles des données du candidat sont approuvés.
• Désactivez les outils ayant des effets secondaires ou redirigez-les vers des mocks.
• Masquez ou tokenisez les champs restreints lorsque cela est requis.
• Limitez le volume et le coût du trafic fantôme.
• Conservez les identifiants de trace de l’outil en place et du candidat liés pour une analyse appariée.
• Ne laissez pas les reprises fantômes consommer le budget de capacité de la route principale.

Les résultats du trafic fantôme doivent être évalués avec les mêmes validateurs et la même taxonomie des échecs que l’ensemble de décision hors ligne.

Déployer le changement de fournisseur par étapes avec un canary

Après validation des seuils hors ligne et du trafic fantôme, exposez une petite portion observable du trafic. Une séquence pratique est :

1. Trafic interne et synthétique.
2. Utilisateurs ou workflows à faible risque.
3. Un petit pourcentage du trafic de production éligible.
4. Augmentations progressives avec une fenêtre d’observation fixe à chaque étape.
5. Déploiement complet uniquement après que le candidat reste dans toutes les garde-fous.

Définissez les déclencheurs automatiques de retour arrière avant de commencer. Parmi les exemples : régression du taux de réussite des tâches, pic d’échecs de schéma, dépassement du p95 de latence, hausse du taux de repli, dépassement de coût ou défaillance critique d’une politique.

Utilisez un routage stable afin que la même conversation, exécution d’agent ou le même client reste sur une seule route lorsque changer en cours de session corromprait l’état. Gardez l’outil en place en préchauffe jusqu’à la fermeture de la fenêtre de retour arrière.

Pour des schémas de fiabilité multi-fournisseurs, consultez le guide de routage de secours des API LLM pour la production.

Conserver une politique de routage après l’évaluation

Le résultat ne doit pas nécessairement être « tout migrer ». De nombreuses équipes obtiennent un meilleur résultat en routant de manière délibérée :

• Une route axée sur la qualité pour les tâches complexes ou à forte valeur.
• Une route à faible coût pour l’extraction et la classification bornées.
• Une route à faible latence pour les suggestions interactives.
• Une route régionale pour les exigences de localisation des données ou de disponibilité.
• Une route de secours pour les limites de débit et les pannes.

Cela rend l’évaluation réutilisable. Chaque route a un contrat, un jeu de données et un budget opérationnel. Les nouveaux candidats se disputent un travail défini au lieu de devenir un autre projet de migration à l’échelle de la plateforme.

Flatkey fournit une couche d’accès compatible OpenAI unique sur plusieurs fournisseurs de modèles, ce qui peut simplifier les tests côte à côte et le routage. Cela n’élimine pas le besoin d’évaluation ; cela réduit le travail d’intégration nécessaire pour exécuter l’évaluation et conserver une option de retour arrière. Comparez les routes actuelles sur la tarification Flatkey.

Modèle de mémo de décision pour un changement de fournisseur

Terminez l’évaluation avec un court document de décision signé :

Joignez les résultats au niveau des cas, la version de l’exécuteur, les prompts, les validateurs, les réponses brutes et l’instantané de tarification. Un futur relecteur devrait pouvoir reproduire pourquoi le changement a été approuvé.

Checklist finale d’évaluation du modèle d’IA

Avant de changer de fournisseur d’API d’IA, confirmez que vous avez :

• Défini le workflow exact et la route candidate.
• Consigné la référence existante et l’enveloppe d’exploitation.
• Constitué des ensembles de développement, de décision retenue et d’audit en production.
• Inclus les cas courants, à forte valeur, de longue traîne, adversariaux, contractuels et opérationnels.
• Figé les prompts, outils, paramètres, entrées de récupération et politique de relance.
• Exécuté des tests appariés entre le modèle en place et le candidat.
• Appliqué des validateurs déterministes avant l’évaluation subjective.
• Calibré tout évaluateur basé sur un modèle par rapport aux humains.
• Défini à l’avance les critères éliminatoires, les pondérations et les marges de non-infériorité.
• Signalé les intervalles de confiance et les résultats par segment.
• Classé les échecs de trace de manière cohérente.
• Testé les schémas, outils, streaming, erreurs, utilisation et limites de débit.
• Calculé le coût effectif par tâche acceptée.
• Effectué des tests de charge sur la concurrence attendue et maximale.
• Terminé la revue de la confidentialité, de la conservation, des aspects régionaux et du contrôle d’accès.
• Passé les contrôles de trafic en shadow et les canary en phase de déploiement.
• Testé le retour arrière automatique et maintenu le modèle en place disponible.
• Signé et archivé la note de décision de changement de fournisseur.

Foire aux questions

Combien de cas de test faut-il pour une évaluation de modèle d’IA ?

Il n’existe pas de nombre universel. Utilisez suffisamment de cas pour couvrir chaque segment important et réduire l’incertitude autour de la décision de migration. Les segments à haut risque ou peu fréquents peuvent nécessiter un suréchantillonnage volontaire. Présentez des intervalles de confiance plutôt que de considérer la taille de l’échantillon comme une preuve en soi.

Dois-je utiliser des benchmarks publics pour choisir un fournisseur d’API ?

Utilisez les benchmarks pour établir une liste restreinte ou comprendre les capacités générales. Ne les utilisez pas comme critère de migration. Vos prompts, outils, schémas, budget de latence, politique de relance, contrôles des données et mix de trafic déterminent l’adéquation à la production.

Une seule URL de base compatible OpenAI peut-elle rendre les fournisseurs interchangeables ?

Elle peut centraliser l’authentification et réduire les changements côté client. Elle ne peut pas garantir une prise en charge identique des paramètres, des sorties structurées, du comportement des outils, des événements de streaming, des limites ou de la qualité du modèle. Testez la matrice de compatibilité pour chaque route que vous utilisez.

Quelle est la métrique la plus importante lors d’un changement de fournisseur ?

Pour la plupart des systèmes d’automatisation, commencez par la réussite du flux de travail de bout en bout. Expliquez ensuite ce résultat à l’aide de la qualité, de la validité du contrat, de la latence, de la fiabilité, des tentatives, du mécanisme de repli et du coût effectif.

Quand devons-nous relancer l’évaluation ?

Relancez-la lorsque la version du modèle, la route du fournisseur, le prompt, les outils, le système de récupération, la tarification, la répartition de la charge de travail, la politique de risque ou l’enveloppe de trafic changent de manière significative. Maintenez une surveillance continue plus légère après le lancement afin que les régressions apparaissent avant la prochaine migration planifiée.

Rendez chaque changement de fournisseur reproductible

L’actif durable n’est pas le modèle gagnant. C’est le système d’évaluation : cas versionnés, capture des traces, validateurs, évaluateurs, tableaux de bord, tests de charge, contrôles de déploiement et registre de décision.

Avec ce système en place, un nouveau fournisseur devient une expérience bornée plutôt qu’une réécriture risquée. Vous pouvez mesurer le candidat par rapport au même contrat de production, l’exposer progressivement et annuler rapidement le changement si la réalité contredit le laboratoire.

Sources

• OpenAI : bonnes pratiques d’évaluation
• OpenAI : travailler avec les évaluations
• Anthropic : définir des critères de réussite et créer des évaluations
• API Anthropic : limites de débit
• API Google Gemini : sorties structurées
• API Google Gemini : appel de fonctions