Politique de routage de modèles
Des règles écrites qui décident quel modèle d'IA prend chaque étape d'un travail — en arbitrant confidentialité, vitesse, coût et qualité — pour que changer de modèle soit un réglage, pas une reconstruction.
Pensez au comptoir d'expédition qui choisit un transporteur pour chaque colis : le fragile part en service haut de gamme, le routinier en service standard, et le confidentiel avec le transporteur assermenté. Une politique de routage, c'est ce comptoir pour les appels d'IA — chaque étape d'un workflow dit ce dont elle a besoin, et le système choisit le modèle qui convient.
Le problème, en mots simples
Vos workflows appellent tous un seul modèle d'IA, parce que c'est comme ça qu'ils ont été bâtis. Puis le fournisseur monte ses prix, ou retire ce modèle, ou un nouveau sort qui est meilleur pour la moitié de vos tâches — et vous découvrez que le nom du modèle est codé en dur à trente endroits. Pendant ce temps, une simple étape de tri oui/non paie le prix du modèle haut de gamme, une étape pressée attend un modèle lent, et une étape qui touche des données sensibles les envoie tranquillement au même service externe que tout le reste. Personne n'a choisi ça. Ça s'est juste accumulé.
Ce que nous mettons en place
Nous sortons le choix du modèle du code pour le mettre dans une politique à la passerelle (la porte d'entrée unique par laquelle passent tous vos appels d'IA). Chaque étape de workflow déclare ses besoins : la vitesse exigée de la réponse (un budget de latence), la sensibilité des données (une classe de confidentialité), la qualité minimale du résultat (un plancher de qualité) et le coût maximal permis (un plafond de coût). La passerelle confronte ces besoins à un catalogue des modèles disponibles — avec les prix et les limites à jour — et choisit la route. Si un fournisseur tombe en panne ou se dégrade, une chaîne de relève déclarée prend le relais. Chaque appel est tracé : vous voyez exactement quel modèle a servi quelle étape, à quel coût.
Comment ça fonctionne, étape par étape
- Chaque étape énonce ses besoins
Vitesse, confidentialité, qualité, coût — déclarés par étape, en termes clairs, là où tout le monde peut les lire.
- La passerelle tient le catalogue
Quels modèles existent, ce qu'ils coûtent, ce qu'ils font bien, où ils s'exécutent — entretenu à un seul endroit au lieu de trente.
- Les appels sont appariés aux modèles
À l'exécution, la passerelle résout les besoins de chaque étape contre le catalogue et route l'appel. Le code du workflow ne nomme jamais de modèle.
- Un pépin déclenche la relève
Une panne ou une baisse de qualité fait glisser les appels le long de la chaîne de relève déclarée, automatiquement — un événement de routage, pas un incident.
- Chaque route est consignée
Les traces montrent quel modèle a traité quel appel : coût et qualité s'attribuent et s'ajustent étape par étape.
Ce qui change pour vous
Avant : un retrait de modèle ou un changement de prix veut dire trouver et modifier chaque endroit où le modèle est nommé, puis croiser les doigts. Après : c'est une modification de la politique de routage — un changement, visible, réversible. L'optimisation des coûts devient une expérience (router cette étape vers un modèle moins cher, surveiller les chiffres de qualité), et un régulateur qui exige un traitement régional devient une règle de routage plutôt qu'une crise. Ce qu'il ne fera pas : décider vos arbitrages à votre place. Qu'une étape privilégie la vitesse sur le coût, ou la confidentialité sur la qualité, reste votre décision — la politique la rend seulement explicite, appliquée et facile à changer.