Il y a deux ans, lors d'une revue d'architecture pour une équipe développant un système de service client transfrontalier, le tableau blanc de la salle de réunion était couvert de comparaisons de scores de différents modèles — MMLU, C-Eval, HumanEval — et on pouvait débattre pendant des heures pour quelques dixièmes de point d'écart. Cette année, en y retournant, la même équipe avait remplacé ces chiffres par une autre série de données : coût moyen par session, latence P99, disponibilité sur sept jours consécutifs. Ce changement n'est pas un cas isolé. Après plusieurs années passées sur des plateformes d'IA, je constate clairement que la logique de sélection des API de grands modèles en entreprise passe du « culte des paramètres » au « bilan d'ingénierie ».
Des classements au bilan comptable : qu'est-ce qui a réellement changé dans la sélection
En résumé, la question centrale de la sélection était autrefois « quel modèle est le plus intelligent » ; elle est désormais « quel modèle est le plus rentable pour cette tâche ». Les scores des classements sont des indicateurs statiques obtenus en conditions de laboratoire, mais en production, vous faites face à des millions d'appels, des pics de trafic fluctuants et des versions de modèles qui changent chaque trimestre. Un modèle classé en tête, si son coût d'inférence est le double d'un autre et sa latence deux fois supérieure, ne tient tout simplement pas la route dans un scénario à un million d'appels par jour. Dans nos projets, nous privilégions désormais la sélection automatique du modèle optimal selon la tâche — les tâches de classification ou de résumé utilisent de petits modèles, seuls les raisonnements complexes sont routés vers de grands modèles — ce qui permet de réduire considérablement le coût global. C'est pourquoi la passerelle de modèles est devenue un standard : elle ne se contente pas de transmettre les requêtes, elle assume des responsabilités de niveau production comme le routage, la dégradation et la limitation de débit.
Trois facteurs qui ont poussé le secteur à ce point de bascule
Le premier est le resserrement de l'écart de capacité entre modèles. La différence entre les modèles de tête et ceux de second rang est passée de « utilisable ou non » à « à quelques détails près ». Pour la grande majorité des scénarios métier, cette différence est imperceptible pour l'utilisateur, mais l'écart de coût, lui, est bien réel. Le deuxième est que les modèles nationaux ont pratiquement rattrapé leur retard sur les scénarios en chinois. Qwen, DeepSeek, Doubao, ERNIE — tous ces modèles sont en fait plus adaptés aux activités nationales en matière de compréhension du chinois, de connaissances localisées et de conformité réglementaire. Auparavant, beaucoup d'équipes fonctionnaient avec « modèles étrangers en principal, modèles nationaux en secours » ; aujourd'hui, c'est l'inverse. Le troisième, et le plus crucial, est le passage des entreprises du stade de démonstration à la production à grande échelle. Au stade de démonstration, le volume d'appels est faible et la sensibilité au coût limitée ; dès que le volume augmente, le coût de chaque appel et la perte liée à chaque dépassement de délai sont amplifiés. À ce moment-là, la sélection n'est plus une question de préférence technique, mais une question financière.
Après ce virage, quels pans d'infrastructure faut-il compléter
Le premier pan est la passerelle de modèles. Elle résout le problème de « gérer tous les modèles via un seul point d'entrée ». Sans passerelle, chaque nouveau modèle intégré implique de modifier le code, de maintenir un jeu de clés et d'écrire une logique de retry. Avec une passerelle, l'intégration multi-modèles est unifiée et le changement de modèle est transparent pour les couches supérieures. Le deuxième pan est l'agrégation d'API d'IA. Sa valeur réside dans l'unification des achats, de la facturation et de la gestion des quotas. Nous avons fait une comparaison en interne : intégrer nous-mêmes les SDK de cinq fournisseurs mobilisait une part considérable du temps d'un ingénieur rien que pour la maintenance de la documentation et la compatibilité des versions ; en passant à une plateforme d'agrégation compatible avec le SDK OpenAI, il suffit de modifier une ligne de base_url pour basculer — ce sont de véritables économies de main-d'œuvre. Mentionnons ici que le positionnement de SiCore TokenWorks, axé sur la priorité aux modèles nationaux et l'ajout de puissance de calcul verte, tombe précisément sur ce point de bascule — ce que les entreprises recherchent, ce n'est pas le plus grand nombre de modèles, mais une couverture nationale complète, des coûts maîtrisés et une orchestration de calcul stable. Le troisième pan est l'observabilité. Sans journaux d'appels, statistiques de consommation de Token ni distribution des latences, vous ne savez tout simplement pas où part l'argent ni quel modèle tire l'ensemble vers le bas. La condition préalable à toute optimisation continue, c'est de pouvoir voir.
Trois prévisions pour la sélection en 2026
Première prévision : la facturation à l'usage deviendra l'option par défaut, et le mode forfaitaire annuel ou mensuel reculera vers quelques rares scénarios à trafic important et stable. Car l'activité elle-même fluctue, et personne ne veut payer pour de la puissance de calcul inutilisée. Deuxième prévision : le routage de modèles passera de « fonctionnalité avancée » à « fonctionnalité de base ». Lorsqu'une entreprise utilise simultanément trois ou quatre modèles devient la norme, la sélection automatique du modèle optimal n'est plus un bonus, mais une nécessité pour économiser. Troisième prévision : la puissance de calcul verte et la souveraineté technologique passeront d'atout bonus à indicateur contraignant. Conformité au programme national de substitution, coût énergétique, stabilité de la chaîne d'approvisionnement — ces trois éléments seront inscrits comme exigences impératives dans davantage de processus d'achat en 2026. L'orchestration de calcul que SiCore TokenWorks déploie entre l'Est et l'Ouest répond essentiellement à cette tendance.
En une phrase : la migration de la logique de sélection consiste essentiellement à passer de « choisir le modèle le plus intelligent » à « choisir la combinaison la plus adaptée ». Pour approfondir les détails de mise en œuvre du routage multi-modèles et de l'agrégation d'API, vous pouvez poursuivre vos recherches autour de la passerelle de modèles, des API de grands modèles et de la facturation à l'usage.