« Quel modèle devons-nous appeler ? » était autrefois une question qui semblait relever de l’API. Dans un nombre croissant d’organisations, elle s’apparente davantage à une question d’approvisionnement, d’ingénierie des performances et d’architecture.
Ce changement découle d’une évolution simple : il existe désormais de nombreux modèles, proposés par de nombreux fournisseurs, avec des atouts, des prix, des profils de latence, des options de déploiement et des conditions contractuelles sensiblement différents. L’accord annoncé par Stripe pour acquérir OpenRouter constitue un signal intéressant. L’API unique d’OpenRouter couvre plus de 400 modèles issus de plus de 80 fournisseurs, avec des critères de routage incluant la complexité de la tâche, le prix, la vitesse, la fiabilité, la latence, le débit et les coûts propres à chaque fournisseur.
Le poste qui émerge ne correspond pas nécessairement à un nouveau titre. Il peut se situer à la croisée de l’ingénierie des plateformes d’IA, de l’architecture, des achats, des opérations d’inférence ou de l’ingénierie produit. Mais sa responsabilité devient identifiable : décider quel modèle doit traiter quel travail, sous quelles contraintes, avec quel mécanisme de repli et sur la base de quelles données.
Le routage est une décision de politique déguisée en infrastructure
Un routeur naïf demande : « Quel modèle est le moins cher ? » Un routeur utile pose une question plus précise : « Quel est le modèle le moins coûteux qui respecte les exigences de qualité, de latence, de fiabilité, de confidentialité et d’exploitation de cette requête ? »
Ces exigences varient selon la tâche. Un classificateur destiné au support client peut avoir besoin d’une sortie structurée prévisible et d’une faible latence. Une tâche de programmation difficile peut justifier un modèle plus lent mais plus performant. Un pipeline de synthèse à haut volume peut privilégier un modèle plus petit, surtout si sa qualité est suffisante après évaluation. Un processus réglementé peut exiger une région particulière, une politique de conservation ou un accord avec un fournisseur donné, quel que soit le prix des tokens.
C’est pourquoi le routage doit être abordé lors des revues d’architecture, et pas uniquement dans le code applicatif. La route détermine davantage qu’une facture. Elle peut avoir une incidence sur la résidence des données, l’exposition aux pannes, l’observabilité, la cohérence des réponses, le comportement d’utilisation des outils et le volume de vérification humaine nécessaire en aval.
Les quatre disciplines qui sous-tendent une véritable fonction de routage
1. Achats : comparer l’ensemble du service, pas seulement le prix affiché des tokens
Les prix des modèles sont faciles à comparer de manière erronée. Les tokens d’entrée et de sortie peuvent avoir des tarifs différents. La mise en cache de l’entrée, le traitement par lots, le service prioritaire et les requêtes avec un contexte long peuvent modifier le calcul. Le prix nominal d’un fournisseur ne dit par ailleurs pas grand-chose sur les nouvelles tentatives, les limites de débit, le support, les engagements minimaux, la sortie de données ou le coût d’ingénierie d’un changement de fournisseur.
Le responsable du routage devrait tenir à jour un inventaire des modèles et des fournisseurs comportant notamment les champs suivants :
- tarification des tokens d’entrée, de sortie, mis en cache et traités par lots ;
- limites de contexte et de sortie ;
- limites de débit documentées et débit observé ;
- distributions de latence, et pas seulement la latence moyenne ;
- disponibilité et comportement en cas d’expiration du délai ;
- conditions relatives à l’utilisation des données, à leur conservation, à leur résidence et au contrat ;
- fonctionnalités prises en charge, notamment les appels d’outils, les sorties structurées, la vision et le streaming ;
- options de repli et de migration.
Le résultat ressemble davantage à une nomenclature des composants technologiques qu’à une liste de noms de modèles. Elle devrait être réexaminée lorsque les prix, les politiques, les versions de modèles ou les volumes d’activité évoluent.
2. Ingénierie des performances : mesurer la tâche, pas le classement
Les benchmarks généraux peuvent aider à s’orienter, mais les décisions de routage nécessitent des tests propres à la charge de travail. Un modèle qui obtient de bons résultats sur un benchmark public de programmation n’est pas forcément le meilleur choix pour les dépôts internes, les conventions de nommage, les schémas d’outils ou les contrôles de sécurité d’une organisation.
Constituez un ensemble d’évaluation représentatif à partir de requêtes réelles, après avoir supprimé les éléments sensibles ou les avoir placés sous contrôle. Étiquetez les résultats importants : exactitude factuelle, validité du JSON, sélection réussie des outils, réussite des tests du code, comportement de refus, nécessité d’une escalade et style acceptable. Enregistrez ensuite le coût, le délai avant le premier token, la latence totale, le taux d’expiration, le taux de nouvelles tentatives et la longueur des réponses.
Ne réduisez pas trop tôt le résultat à un score unique. Un score pondéré peut masquer un mode de défaillance grave. Par exemple, un modèle dont la qualité moyenne est excellente mais qui produit fréquemment des appels d’outils mal formés peut être inadapté à un processus automatisé. Un modèle plus lent peut être préférable sur le plan économique si ses réponses réduisent le coûteux contrôle humain.
Utilisez un processus de type champion-défi : conservez une route actuellement approuvée, testez les solutions de remplacement sur le même corpus et ne promouvez un challenger que lorsqu’il dépasse des seuils explicites de qualité et d’exploitation. Les affirmations communiquées par les fournisseurs doivent être considérées comme des éléments d’un plan de test, et non comme la preuve qu’un modèle aura des performances similaires dans votre environnement.
3. Architecture : rendre le choix du modèle interchangeable
Le routage devient coûteux lorsque des hypothèses propres aux modèles se répandent dans toute une application. Une conception résiliente sépare la tâche métier de l’appel au fournisseur.
Définissez un contrat interne de capacités. Il peut préciser qu’une opération de « classification » renvoie un schéma fixe, des champs de confiance ou d’abstention, un identifiant de modèle et un identifiant de traçage. Une opération de « rédaction de réponse » peut préciser des contraintes de ton, des exigences de citation et un budget maximal de latence. Les adaptateurs des fournisseurs traduisent ensuite ce contrat pour chaque API.
Conservez les invites, les schémas, les définitions d’outils, les règles de sécurité et les politiques de routage sous gestion de versions. Enregistrez quel instantané de modèle et quel fournisseur ont traité chaque requête. Conservez suffisamment d’informations pour reproduire une décision sans conserver inutilement le contenu sensible de l’utilisateur.
Concevez délibérément les solutions de repli. Il peut s’agir d’un autre fournisseur, d’un modèle plus petit, d’un workflow mis en file d’attente ou d’un parcours de revue humaine. La solution de repli ne doit pas modifier silencieusement le sens de la tâche. Si une sortie structurée est obligatoire, elle doit prendre en charge le même contrat ou déclencher une escalade contrôlée.
4. Gouvernance : décider quand ne pas router automatiquement
Certaines requêtes ne devraient pas être envoyées au modèle disponible le moins cher — ni à aucun modèle externe. La politique de routage doit prévoir des règles d’exclusion pour les données confidentielles, les décisions à fort impact, les langues non prises en charge, les contextes exceptionnellement longs ou les actions nécessitant une étape d’approbation humaine.
Les équipes devraient également distinguer le fait qu’un modèle soit techniquement disponible de celui qu’il soit approuvé pour un usage particulier. Les exigences en matière d’achats et de droit peuvent différer selon l’unité opérationnelle. Un modèle peut être excellent lors d’une évaluation tout en étant inutilisable pour un workflow dont les conditions de traitement des données ne conviennent pas à l’organisation.
Un tableau de routage pratique
Une politique de départ peut être simple et explicite :
| Classe de tâche | Objectif principal | Route possible | Déclencheur d’escalade |
|---|---|---|---|
| Extraction à gros volume | Schéma valide et faible coût unitaire | Modèle de petite ou moyenne taille avec validation stricte de la sortie | Échec du schéma ou faible confiance |
| Analyse complexe | Qualité et gestion des éléments probants | Modèle plus performant avec un budget de latence plus élevé | Éléments probants manquants, ambiguïté ou signalement par la politique |
| Assistance interactive | Réponse perçue comme rapide | Modèle à faible latence, éventuellement suivi d’un affinement | Faible niveau de confiance ou demande de l’utilisateur pour davantage de profondeur |
| Flux de travail sensible | Traitement des données approuvé et auditabilité | Fournisseur approuvé par le contrat ou déploiement contrôlé | Données, action ou juridiction non approuvées |
Le tableau exact variera selon l’organisation. L’important est que les règles de routage soient lisibles par les parties prenantes des équipes produit, sécurité, finance et ingénierie, et non enfouies dans une instruction conditionnelle.
Ce que cela signifie pour les personnes qui construisent leur carrière
Les meilleurs candidats pour ce travail combineront plusieurs types de compétences. Ils comprendront suffisamment l’apprentissage automatique pour raisonner sur les capacités et leur dégradation ; suffisamment l’ingénierie des systèmes pour gérer la latence, les nouvelles tentatives, les limites de débit et les modes de défaillance ; suffisamment la finance pour modéliser le coût total ; et suffisamment les achats et la gouvernance pour évaluer les engagements et les restrictions des fournisseurs.
Ils seront également à l’aise avec la rédaction de comptes rendus de décision. Un compte rendu utile explique pourquoi un routage a été sélectionné, quelles preuves l’étayent, quels risques subsistent et quel événement devrait déclencher une réévaluation. Cela vaut davantage que mémoriser les derniers noms de modèles, car les noms des modèles et leurs prix continueront de changer.
Un projet de portfolio compact pourrait démontrer cette compétence sans nécessiter un vaste système de production. Prenez une charge de travail, créez un jeu d’évaluation expurgé, connectez trois fournisseurs de modèles ou modèles locaux derrière une interface commune, puis comparez la qualité, la validité du schéma, les percentiles de latence, les taux d’échec et le coût mensuel estimé pour plusieurs volumes. Ajoutez des règles de politique pour les entrées sensibles ainsi qu’un chemin de repli. Publiez la méthodologie de test et ses limites.
Soyez précis sur ce que le projet démontre. Il ne démontre pas qu’un modèle est universellement le meilleur. Il démontre que vous pouvez transformer un problème ambigu de choix de modèle en une politique opérationnelle mesurable.
Le signal de carrière
Le routage des modèles devient stratégiquement important parce que l’intelligence n’est plus une dépendance unique et fixe. Il s’agit d’un portefeuille de services présentant des compromis différents et une économie en évolution. Les équipes qui traitent ce portefeuille comme une infrastructure interchangeable peuvent réduire les coûts, mais elles peuvent aussi créer des problèmes cachés de qualité, de conformité et de fiabilité. Les équipes qui le traitent comme un engagement permanent envers un modèle unique risquent de passer à côté de meilleures options.
La discipline émergente se situe entre ces deux extrêmes : suffisamment abstraite pour changer de fournisseur, suffisamment spécifique pour préserver la qualité des tâches, et suffisamment fondée sur les faits pour justifier le choix. Voilà l’opportunité professionnelle liée au routage des modèles : non pas choisir une API une fois pour toutes, mais construire le système décisionnel qui continue de faire les bons choix.
Tom Whitfield est le rédacteur humain responsable de AI Career Brief, qui traite des compétences, des rôles et des décisions judicieuses pour travailler à l’ère de l’IA.
