La compatibilité fixe la forme ; le contrat fixe le comportement
Un format commun de requête et de réponse réduit les changements côté application et facilite le passage d’un modèle ou fournisseur à un autre. Il permet aussi de placer l’accès derrière une interface. Mais des champs identiques ne disent pas si la requête a été acceptée, quel fournisseur l’a exécutée, quand la relancer, comment classer une réponse partielle ni comment rapprocher la consommation finale. Dès qu’une équipe dépend du système, ces questions appartiennent au contrat du produit.
Une passerelle doit donc définir les limites de validation, d’admissibilité et de politique, de choix de route, d’exécution, de qualification du résultat et de preuve de consommation. Ce sont des responsabilités de conception, pas l’affirmation que toutes les passerelles les réalisent de la même manière. Un échange HTTP réussi ne prouve pas que le travail est terminé. À l’inverse, le client peut perdre la réponse après l’exécution chez le fournisseur. Classer les deux cas comme une simple erreur masque la décision à prendre.
Un flux est une suite de preuves, pas une réponse unique
Le streaming permet d’afficher le début d’un texte pendant que le modèle continue de le produire. Le flux HTTP documenté par OpenAI, par exemple, utilise des événements envoyés par le serveur et distingue les fragments de texte d’un événement de fin. L’application peut montrer un début utile sans savoir si la réponse est complète. Si elle reçoit deux paragraphes puis perd la connexion, le texte visible ne prouve pas que l’opération est terminée. [2]
La passerelle devrait conserver ce qu’elle sait : l’identité de la requête, la route choisie, l’acceptation en amont, les événements observés et la confirmation ou non de la fin. La réponse partielle visible doit rester distincte d’un résultat final. C’est une recommandation d’architecture, pas une promesse de reprise possible chez tous les fournisseurs. Le système peut afficher un résultat incomplet, demander une décision avant une nouvelle tentative ou consulter un enregistrement du fournisseur s’il existe. Il faut nommer l’incertitude au lieu de la transformer discrètement en succès ou en échec.
Avant de relancer, compter avec le risque de doublon
Prenons une demande de rédaction explicitement fictive. Le fournisseur commence à diffuser le texte ; l’application reçoit deux paragraphes, puis la connexion expire. Le fournisseur peut continuer à générer et facturer le travail déjà accompli. Si l’application renvoie immédiatement la même demande, elle peut créer une seconde génération et un second coût, même si elle n’affiche qu’une réponse. L’expiration ne prouve pas que le premier essai n’a jamais eu lieu. La documentation Chat Completions d’OpenAI précise aussi qu’un flux interrompu peut priver le client du bloc final contenant la consommation totale. [3]
La sémantique HTTP rend la prudence précise : un client ne doit pas relancer automatiquement une opération non idempotente sans savoir qu’elle est effectivement idempotente ou que la première n’a pas été appliquée ; un proxy ne doit pas la relancer. La génération passe souvent par POST, et la forme familière de l’API ne suffit donc pas. [1] Une politique peut autoriser une reprise avant l’envoi, employer un mécanisme d’idempotence proposé par le fournisseur, ou exiger un nouvel essai explicite après un flux ambigu. Le compromis oppose rapidité et confort au risque de doublons et de coûts incertains.
Décider si l’exécution est permise avant de choisir où
Le routage choisit où exécuter une requête admissible. La politique détermine si elle peut l’être et sous quelles contraintes. Une tâche peut imposer une modalité, une longueur de contexte, une région, des fournisseurs approuvés, des permissions d’outils ou un plafond de dépense. Si le fournisseur préféré est indisponible, une solution de repli n’est utile que si elle respecte encore ces contraintes. Basculer en silence vers une route inadmissible change l’accord avec l’application.
Un parcours illustratif serait : valider la requête → appliquer politique et budget → choisir une route admissible → exécuter avec délai → qualifier le résultat → enregistrer la consommation observée → produire l’événement de facturation dans le système propre au produit. Il ne décrit pas des mécanismes internes déjà livrés dans RouterShift. Routage, reprise et comptabilité doivent rester explicables séparément. Une règle déterministe s’audite plus facilement ; une sélection adaptative peut aider avec des données fiables, mais impose d’expliquer le choix.
Mesurer ce qui est observé avant d’en faire un montant
Une requête, une tentative et le relevé final du fournisseur sont trois faits distincts. Si le flux se coupe, la consommation finale peut manquer ; estimer les tokens à partir du texte visible ne justifie pas une charge présentée comme définitive. Il faut conserver le relevé d’origine, l’identifiant de tentative et la base de toute estimation. Quand une mesure faisant autorité arrive, elle peut être rapprochée ; les corrections doivent rester traçables. [3]
Les conventions actuelles d’OpenTelemetry pour l’IA générative nomment les tokens d’entrée et de sortie, le modèle, le fournisseur et les catégories d’erreur. C’est un vocabulaire de télémétrie, pas un système de facturation ni une garantie d’unités identiques partout. Elles rappellent aussi que les messages enregistrés peuvent contenir des données sensibles. [4] Tarification et mouvements de solde viennent après la mesure, avec devise, version de tarif et piste d’audit. Image, audio et vidéo peuvent nécessiter d’autres unités que les tokens.
Rendre le contrat visible dans l’exploitation courante
Lors d’un incident, l’équipe doit pouvoir répondre : quelle requête est touchée ? Quelle route a été retenue et pourquoi ? Le fournisseur l’a-t-il acceptée ? La sortie est-elle complète ? Quelle consommation est confirmée, estimée ou inconnue ? Quelles versions de politique et de prix étaient appliquées ? Identifiants de requête et de tentative, états de résultat et liens de traces permettent de répondre sans journaliser les prompts par défaut. L’interface doit être lisible pour l’équipe d’exploitation, pas seulement pour les développeurs.
Ces questions permettent aussi d’éprouver les promesses d’une passerelle. Si la panne survient avant l’envoi, une autre route admissible peut convenir. Si le flux se coupe après le début de la génération, le système doit déclarer le résultat incomplet ou incertain et expliquer la suite possible. Si la mesure manque, il faut attendre son rapprochement. La compatibilité réduit le coût d’entrée ; le contrat de production rend le comportement prévisible hors du cas idéal. RouterShift est le produit actif de SlateMoth pour l’accès aux modèles. Ce cadre expose un problème de conception, sans prétendre que chaque mécanisme décrit y soit déjà livré.